Data processing system, data processing device, data processing method, and computer program

ABSTRACT

A privilege management system enabling effective privilege management, such as confirmation processing of service receiving privileges and so forth, is realized. A group attribute certificate which has, as stored information, group identification information corresponding to a group which is a set of certain devices or certain users, and also has affixed an electronic signature of an issuer, is issued to a service reception entity, and verification is performed by means of signature verification for of the group attribute certificate presented from the user device regarding whether or not there has been tampering, screening is performed regarding whether or not this is a service-permitted group based on group identification information stored in the group attribute certificate by using a group information database, and determination is made regarding whether or not service can be provided, based on the screening. Centralized privilege confirmation corresponding to various user sets or device sets can be made, so management of individual privilege information can be omitted, thereby enabling effective privilege management.

TECHNICAL FIELD

The present invention relates to a data processing system, a dataprocessing device, a method thereof, and a computer program. Moreparticularly, the present invention relates to a data processing system,a data processing device, a method thereof, and a computer program,whereby service receiving privilege management for users requiringconfirmation in contents usage for example, or service usage processingor the like, is executed in an effective and secure manner, and dataprocessing is executed based on access privilege confirmation of usersor devices.

BACKGROUND ART

As of recent, there is a great deal of service providing processingaccompanying communication between terminals, such as distribution ofvarious types of software data such as music data, image data, gameprograms, and so forth (hereafter referred to as Content) viacommunication networks such as the Internet or distributable storagemedia such as DVDs, CDs, memory cards, and the like, and paymentaccompanying data transmission/reception between terminals. For example,users having various types of user devices, such as PCs, portablecommunication terminals, portable devices, memory cards, or the like,making connection with service providing devices of service providers inthe home or out of the home to exchange data between devices or toreceive contents or service, is becoming an increasing everydayoccurrence.

Specific examples of the various service usages include accessing acontents distribution service provider using a PC or portable terminalor the like to download various types of contents such as music, movingpictures, game programs, and so forth, shopping or transferring fundsusing a memory card or the like having a built-in IC chip storingpersonal information, bank account information, shopping limit monetaryamount information, or the like, and using in the stead of tickets attrain stations or for busses or the like.

While distribution of contents and services and the like via suchcommunication networks or media is becoming more commonplace, on theother hand, there is the problem of unauthorized use of contents orservices, i.e., use of services by users not having proper privileges,and development of a system whereby contents or services or the like areprovided only to users having proper usage privileges in a sure manner,thereby eliminating unauthorized use of services, is awaited.

For example, with many software contents, such as music data, imagedata, game programs, etc., the creator or vendor generally holds therights to distribution thereof, and with distribution of such contents,a system taking security into consideration is employed, whereby usageof the software is permitted under certain usage restrictions, i.e.,only to authorized users, such that duplication or the like withoutpermission is not performed.

One means by which usage restriction of devices or users receivingservices is realized is encryption processing. For example, there is anarrangement wherein, at the time of providing content or serviceinformation for example to a device or user, the content or serviceinformation is encrypted and provided, with a decryption key capable ofbeing used on by an authorized device or user being distributed thereto,thereby enabling usage of the content or service. The encrypted data canbe returned to decrypted data (plaintext) by decryption processing usingthe decryption key.

While there are various data encryption/decryption methods andarrangements using an encryption key and decryption key, one example isa method called the shared key encryption method. With the shared keyencryption method, the encryption key used for the data encryptionprocessing, and the decryption key used for the data decryptionprocessing, are shared, and authorized users are provided with a sharedkey to use for the encryption processing and decryption processing,thereby eliminating data access by unauthorized users which do not havethe key. A representative method of this method is DES (Data EncryptionStandard).

Also, a method wherein processing with an encryption key used forencryption and processing with a decryption key used for decryption, isthe so-called public key encryption method. The public key encryptionmethod is a method using a public key, which unspecified users can use,wherein an encrypted document for a specified individual is subjected toencryption processing using a public key which the specific individualhas generated. The document encrypted by the public key can only bedecrypted by a secret key corresponding to the public key used for theencryption processing. Only the individual which has generated thepublic key has the secret key, so only the individual which has thesecret key can decrypt the document encrypted with the public key. Arepresentative example of the pubic key encryption method is ellipticcurve encryption, or RSA (Rivest-Shamir-Adleman) encryption. Using suchencryption methods enable a system wherein encrypted content scan bedecrypted only by the authorized user.

With a content or service usage management arrangement such as describedabove, there are known methods for determining whether or not anauthorized user by performing authentication processing between theservice provider which provides the contents or services and the userdevice such as a PC, portable terminal, memory card, etc., beforeproviding encrypted data such as content or service information or thelike, or before providing a decryption key. In general authenticationprocessing, the other party is confirmed, and a session key which isvalid only for that communication is generated, and in the event thatauthentication is established, communication is carried out byencrypting the data of the content or the decryption key or the like,using the generated session key.

DISCLOSURE OF INVENTION

While there is a technique for executing confirmation of user privilegesby executing authentication processing between the service providerwhich provides services and the user on a one-on-one basis as with thesystem for confirming user privileges described above, development of asystem wherein execution of presence/absence of service usage privilegesof individual users or user terminals can be performed in an effectiveand secure manner is desired, in light of increasing variation ofservices which can be executed at user terminals such as contentproviding services, other information usage services, payment services,and so forth.

The present invention has been made in light of the above problem, andaccordingly it is an object of the present invention to provide a dataprocessing system, a data processing device, a method thereof, and acomputer program, whereby, in a data processing system for executingdata processing accompanied by data communication, accuratedetermination of whether or each device or user with which communicationis being made has proper data processing execution privileges or servicereceiving privileges can be made thereby realizing data processingwithout mistake.

For example, it is an object thereof to provide a device and method forscreening whether or not an access is from a user or communicationdevice recognized at a communication processing device which is to beaccessed, based on attribute certificates, and permitting access onlyfrom users or devices having access privileges, thereby eliminatingaccess from other devices.

A first aspect of the present invention is a privilege management systemfor managing service reception privileges of user devices;

wherein a user device which is a service reception entity holds a groupattribute certificate which has, as stored information, groupidentification information corresponding to a group which is a set ofcertain devices or certain users, and also has affixed an electronicsignature of an issuer;

and wherein a service provider which is a service providing entity has aconfiguration for executing verification, by means of signatureverification, of the group attribute certificate presented from the userdevice regarding whether or not there has been tampering, performingscreening regarding whether or not this is a service-permitted groupbased on group identification information stored in the group attributecertificate, and executing determination regarding whether or notservice can be provided, based on the screening.

Further, with an arrangement of the privilege management systemaccording to the present invention, the group attributes certificate isa certificate issued to a user device corresponding to a device or auser, under the conditions that mutual authentication is establishedbetween a group attributes certificate issuing entity and the userdevice, and that the device or user to which the certificate is to beissued is following an issuance policy permitted by the serviceprovider.

Further, with an arrangement of the privilege management systemaccording to the present invention, the issuing processing for a newgroup attributes certificate is of a configuration carried out under thecondition that verification is established at the group attributescertificate issuing entity regarding an already-issued group attributescertificate which the user device already holds.

Further, with an arrangement of the privilege management systemaccording to the present invention, the service provider is of aconfiguration having a group information database wherein the groupidentifier and permitted service information for members belonging tothe group are correlated, wherein the group information database issearched based on the group identification information stored in thegroup attributes certificate presented by the user device, anddetermining processing regarding whether or not service can be providedis executed.

Further, with an arrangement of the privilege management systemaccording to the present invention, the service provider is of aconfiguration wherein screening regarding whether or not the object ofservice permission is executed for each of a plurality of sets ofdifferent group identification information obtained from a plurality ofgroup attribute certificates based on a plurality of different groupdefinitions presented by the user device, and determining processingregarding whether or not service can be provided is executed under thecondition that all group identification sets are the object of servicepermission.

Further, with an arrangement of the privilege management systemaccording to the present invention, the service provider is of aconfiguration wherein screening regarding whether or not the object ofservice permission is executed for first group identificationinformation obtained from a first group attribute certificate based ongroup definitions from the user device wherein devices are groupmembers, and screening regarding whether or not the object of servicepermission is executed for second group identification informationobtained from a second group attribute certificate based on groupdefinitions from the user device wherein devices are group users, anddetermining processing regarding whether or not service can be providedis executed under the condition that all group identification sets arethe object of service permission.

Further, with an arrangement of the privilege management systemaccording to the present invention, the user device is of aconfiguration including an end entity as a device for executingcommunication with the service provider, and a user identificationdevice as an individual identification device; wherein the groupattribute certificate is issued individually to each of the end entityand user identification device, with issuing processing being carriedout under the condition that mutual authentication has been establishedbetween the group attribute certificate issuing entity and the endentity or the user identification device.

Further, an arrangement of the privilege management system according tothe present invention is of a configuration wherein the group attributecertificate is an attribute certificate issued by an attributeauthority, and a group identifier is stored in an attribute informationfiled within the attribute certificate.

Further, with an arrangement of the privilege management systemaccording to the present invention, the group attribute certificate isof a configuration storing link information regarding a public keycertificate corresponding to the group attribute certificate; whereinthe service provider is of a configuration wherein verification of thepublic key certificate obtained by the link information is also executedat the time of performing verification of the group attributecertificate.

Further, a second aspect of the present invention is an informationprocessing device for executing data processing as service providingprocessing, comprising:

a data reception unit for receiving a group attribute certificate whichhas, as stored information, group identification informationcorresponding to a group which is a set of certain devices or certainusers, and also has affixed an electronic signature of an issuer as anattribute certificate to be applied to service usage privilegeconfirmation processing from a service providing device; and

a group attribute certificate verification processing unit for executingverification, by means of signature verification, of the group attributecertificate regarding whether or not there has been tampering,performing screening regarding whether or not this is aservice-permitted group based on group identification information storedin the group attribute certificate, and executing determinationregarding whether or not service can be provided, based on thescreening.

Further, an arrangement of the information processing device accordingto the present invention is of a configuration further comprising agroup information database wherein the group identifier and permittedservice information for members belonging to the group are correlated;wherein the group attribute certificate verification processing unitsearches the group information database based on the groupidentification information stored in the group attributes certificatepresented by the user device, and executes determining processingregarding whether or not service can be provided.

Further, with an arrangement of the information processing deviceaccording to the present invention, the group attribute certificateverification processing unit is of a configuration wherein screeningregarding whether or not the object of service permission is executedfor each of a plurality of sets of different group identificationinformation obtained from a plurality of group attribute certificatesbased on a plurality of different group definitions presented by theuser device, and determining processing regarding whether or not servicecan be provided is executed, based on the screening.

Further, a third aspect of the present invention is a privilegemanagement method for managing service reception privileges of userdevices, comprising:

as an execution step at a user device which is a service receptionentity, a step for transmitting to a service provider which is a serviceproviding entity a group attribute certificate which has, as storedinformation, group identification information corresponding to a groupwhich is a set of certain devices or certain users, and also has affixedan electronic signature of an issuer;

and, as an execution step at the service provider, a step for performingverification, by means of signature verification, of the group attributecertificate presented from the user device regarding whether or notthere has been tampering, performing screening regarding whether or notthis is a service-permitted group based on group identificationinformation stored in the group attribute certificate, and executingdetermination regarding whether or not service can be provided, based onthe screening.

Further, an arrangement of the privilege management method according tothe present invention further comprising a group attribute certificateissuing processing step for issuing the group attributes certificate toa user device corresponding to a device or a user; wherein the groupattribute certificate issuing processing step is a processing step forissuing the group attribute certificate to a user device correspondingto a device or a user under the conditions that mutual authentication isestablished between a group attributes certificate issuing entity andthe user device, and that the device or user to which the certificate isto be issued is following an issuance policy permitted by the serviceprovider.

Further, with an arrangement of the privilege management methodaccording to the present invention, the group attribute certificateissuing processing step includes a verification processing stepregarding an already-issued group attributes certificate which the userdevice already holds, wherein issuing of a group attributes certificateis carried out under the condition that the verification is established.

Further, with an arrangement of the privilege management methodaccording to the present invention, the service provider is of aconfiguration having a group information database wherein the groupidentifier and permitted service information for members belonging tothe group are correlated, wherein the group information database issearched based on the group identification information stored in thegroup attributes certificate presented by the user device, anddetermining processing regarding whether or not service can be providedis executed.

Further, with an arrangement of the privilege management methodaccording to the present invention, the service provider is of aconfiguration wherein screening regarding whether or not the object ofservice permission is executed for each of a plurality of sets ofdifferent group identification information obtained from a plurality ofgroup attribute certificates based on a plurality of different groupdefinitions presented by the user device, and determining processingregarding whether or not service can be provided is executed under thecondition that all group identification sets are the object of servicepermission.

Further, with an arrangement of the privilege management methodaccording to the present invention, at the service provider, screeningregarding whether or not the object of service permission is executedfor first group identification information obtained from a first groupattribute certificate based on group definitions from the user devicewherein devices are group members, and screening regarding whether ornot the object of service permission is executed for second groupidentification information obtained from a second group attributecertificate based on group definitions from the user device whereindevices are group users, and determining processing regarding whether ornot service can be provided is executed under the condition that allgroup identification sets are the object of service permission.

Further, with an arrangement of the privilege management methodaccording to the present invention, the group attribute certificate isof a configuration storing link information regarding a public keycertificate corresponding to the group attribute certificate; and theservice provider is of a configuration wherein verification of thepublic key certificate obtained by the link information is also executedat the time of performing verification of the group attributecertificate.

Further, a fourth aspect of the present invention is an informationprocessing method for an information processing device for executingdata processing as service providing processing, the method comprising:

a certificate reception step for receiving from a service providingdevice, a group attribute certificate which has, as stored information,group identification information corresponding to a group which is a setof certain devices or certain users, and also has affixed an electronicsignature of an issuer, as an attribute certificate to be applied toservice usage privilege confirmation processing; and

a group attribute certificate verification processing step for executingverification, by means of signature verification of the group attributecertificate, regarding whether or not there has been tampering,performing screening regarding whether or not this is aservice-permitted group based on group identification information storedin the group attribute certificate, and executing determinationregarding whether or not service can be provided, based on thescreening.

Further, with an arrangement of the information processing methodaccording to the present invention, the information processing devicefurther comprises a group information database wherein the groupidentifier and permitted service information for members belonging tothe group are correlated; wherein the group attribute certificateverification processing step includes a step for searching the groupinformation database based on the group identification informationstored in the group attributes certificate presented by the user device,and executing determining processing regarding whether or not servicecan be provided.

Further, with an arrangement of the information processing methodaccording to the present invention, the group attribute certificateverification processing step includes a step for executing screeningregarding whether or not the object of service permission is executedfor each of a plurality of sets of different group identificationinformation obtained from a plurality of group attribute certificatesbased on a plurality of different group definitions presented by theuser device, and executing determining processing regarding whether ornot service can be provided under the condition that all groupidentification sets are the object of service permission.

Further, a fifth aspect of the present invention is a computer programfor effecting execution of privilege management processing for managingservice reception privileges of user devices, the program comprising:

a certificate reception step for receiving from a service providingdevice, a group attribute certificate which has, as stored information,group identification information corresponding to a group which is a setof certain devices or certain users, and also has affixed an electronicsignature of an issuer, as an attribute certificate to be applied toservice usage privilege confirmation processing; and

a group attribute certificate verification processing step for executingverification, by means of signature verification of the group attributecertificate, regarding whether or not there has been tampering,performing screening regarding whether or not this is aservice-permitted group based on group identification information storedin the group attribute certificate, and executing determinationregarding whether or not service can be provided, based on thescreening.

Further, a sixth aspect of the present invention is an access privilegemanagement system for executing access restrictions betweencommunication devices having communication functions;

wherein an access requesting device stores, in storage means, a groupattribute certificate which has, as stored information, groupidentification information corresponding to a group which is a set ofcertain communication devices or certain users, and also has affixed anelectronic signature of an issuer;

and wherein an access requested device, which is the object of an accessrequest from the access requesting device, executes verification, bymeans of signature verification, of the group attribute certificatepresented from the access requesting device regarding whether or notthere has been tampering, performing screening regarding whether or notthe access requesting device is a device which belongs to anaccess-permitted group based on group identification information storedin the group attribute certificate, and executes determination regardingwhether or not access can be permitted, based on the screening.

Further, with an arrangement of the access privilege management systemaccording to the present invention, the access requested device has aconfiguration for performing screening regarding whether or not theaccess requesting device is an end entity belonging to anaccess-permitted group, based on a group attribute certificate issued tothe end entity which is an access executing device making up the accessrequesting device, and executing determination regarding whether or notaccess can be permitted, based on the screening.

Further, with an arrangement of the access privilege management systemaccording to the present invention, the access requested device has aconfiguration for performing screening regarding whether or not theaccess requesting device is a device owned by a user belonging to anaccess-permitted group, based on a group attribute certificate issued toa user identification device which is an individual identificationdevice making up the access requesting device, and executingdetermination regarding whether or not access can be permitted, based onthe screening.

Further, an arrangement of the access privilege management systemaccording to the present invention is of a configuration wherein theaccess requesting device and the access requested device have securitychips with anti-tampering configurations, with mutual authenticationbeing executed between the mutual security chips, and wherein, under thecondition that mutual authentication has been established, the accessrequested device executes signature verification of the group attributecertificate presented from the access requesting device, and screeningregarding whether or not the device belongs to an access-permittedgroup.

Further, an arrangement of the access privilege management systemaccording to the present invention is of a configuration wherein theaccess requested device receives from a device an issuing request for agroup attribute certificate certifying that the device is anaccess-permitted group member; and, under the conditions that mutualauthentication between devices has been established and that the groupattribute certificate issue requesting device is following an issuancepolicy permitted by the access requested device, issues a groupattribute certificate to a device corresponding to a device or a user,certifying that the device is an access-permitted group member.

Further, an arrangement of the access privilege management systemaccording to the present invention is of a configuration wherein theaccess requested device receives from a device an issuing request for agroup attribute certificate certifying that the device is anaccess-permitted group member; and, under the conditions that mutualauthentication between devices has been established and thatverification and screening is established for an already-issued groupattribute certificate already held by the group attribute certificateissue requesting device, issues a group attribute certificate to adevice corresponding to a device or a user, certifying that the deviceis an access-permitted group member.

Further, with an arrangement of the access privilege management systemaccording to the present invention, the group attribute certificate isof a configuration storing link information regarding a public keycertificate corresponding to the group attribute certificate; and theaccess requesting device is of a configuration wherein verification ofthe public key certificate obtained by the link information is alsoexecuted at the time of performing verification of the group attributecertificate.

Further, a seventh aspect of the present invention is a communicationprocessing device for executing access restriction processing,comprising:

a reception unit for receiving, from an access requesting device, agroup attribute certificate which has, as stored information, groupidentification information corresponding to a group which is a set ofcertain communication devices or certain users, and also has affixed anelectronic signature of an issuer; and

an access privilege determination processing unit for executing groupattribute certificate verification processing functions, for executingverification, by means of signature verification, of the group attributecertificate received from the access requesting device regarding whetheror not there has been tampering, performing screening regarding whetheror not the access requesting device is a device which belongs to anaccess-permitted group based on group identification information storedin the group attribute certificate, and executing determinationregarding whether or not access can be permitted, based on thescreening.

Further, with an arrangement of the communication processing deviceaccording to the present invention, the access privilege determinationprocessing unit has a configuration for performing screening regardingwhether or not the access requesting device is an end entity belongingto an access-permitted group, based on a group attribute certificateissued to the end entity which is an access executing device at theaccess requesting device, and executing determination regarding whetheror not access can be permitted, based on the screening.

Further, with an arrangement of the communication processing deviceaccording to the present invention, the access privilege determinationprocessing unit has a configuration for performing screening regardingwhether or not the access requesting device is a device owned by a userbelonging to an access-permitted group, based on a group attributecertificate issued to a user identification device which is anindividual identification device making up the access requesting device,and executing determination regarding whether or not access can bepermitted, based on the screening.

Further, an arrangement of the communication processing device accordingto the present invention comprises an encipherment processing unit forexecuting mutual authentication with the access requesting device;wherein the access privilege determination processing unit has aconfiguration for, under the condition that mutual authentication hasbeen established, executing signature verification of the groupattribute certificate presented from the access requesting device, andscreening regarding whether or not the device belongs to anaccess-permitted group.

Further, an arrangement of the communication processing device accordingto the present invention further comprises an attribute certificategenerating unit for generating a group attribute certificate which has,as stored information, group identification information corresponding toa group which is a set of certain communication devices or certainusers, and also has affixed an electronic signature of an issuer.

Further, with an arrangement of the communication processing deviceaccording to the present invention, the group attribute certificate isof a configuration storing link information regarding a public keycertificate corresponding to the group attribute certificate; and theaccess privilege determination processing unit is of a configurationwherein verification of the public key certificate obtained by the linkinformation is also executed at the time of performing verification ofthe group attribute certificate.

Further, an eighth aspect of the present invention is an accessprivilege management method for executing access restrictions betweencommunication devices having communication functions, the methodcomprising:

a step for an access requesting device to transmit to an accessrequested device, which is the object of an access request, a groupattribute certificate which has, as stored information, groupidentification information corresponding to a group which is a set ofcertain communication devices or certain users, and also has affixed anelectronic signature of an issuer;

a step for the access requested device to receive the group attributecertificate presented by the access requesting device;

a screening step for executing verification, by means of signatureverification, of the group attribute certificate presented from theaccess requesting device regarding whether or not there has beentampering, and performing screening regarding whether or not the accessrequesting device is a device which belongs to an access-permitted groupbased on group identification information stored in the group attributecertificate;

and a step for executing determination regarding whether or not accesscan be permitted, based on the screening results in the screening step.

Further, with an arrangement of the access privilege management methodaccording to the present invention, the access requested device performsscreening regarding whether or not the access requesting device is anend entity belonging to an access-permitted group, based on a groupattribute certificate issued to the end entity which is an accessexecuting device at the access requesting device, and executingdetermination regarding whether or not access can be permitted, based onthe screening.

Further, with an arrangement of the access privilege management methodaccording to the present invention, the access requested device performsscreening regarding whether or not the access requesting device is adevice owned by a user belonging to an access-permitted group, based ona group attribute certificate issued to a user identification devicewhich is an individual identification device at the access requestingdevice, and executing determination regarding whether or not access canbe permitted, based on the screening.

Further, an arrangement of the access privilege management methodaccording to the present invention further comprises a mutualauthentication execution step between security chips with anti-tamperingconfigurations of the access requesting device and the access requesteddevice; wherein, under the condition that mutual authentication has beenestablished, the access requested device executes signature verificationof the group attribute certificate presented from the access requestingdevice, and screening regarding whether or not the device belongs to anaccess-permitted group.

Further, an arrangement of the access privilege management methodaccording to the present invention further comprises a step for theaccess requested device to receive from a device an issuing request fora group attribute certificate certifying that the device is anaccess-permitted group member; and a step wherein, under the conditionsthat mutual authentication between devices has been established and thatthe group attribute certificate issue requesting device is following anissuance policy permitted by the access requested device, a groupattribute certificate is issued to a device corresponding to a device ora user.

Further, an arrangement of the access privilege management methodaccording to the present invention further comprises, as an executionstep at the access requested device in response to an issuing requestfrom a device for a group attribute certificate certifying that thedevice is an access-permitted group member, a step for executingprocessing for issuing a group attribute certificate to a devicecorresponding to a device or a user, certifying that the device is anaccess-permitted group member, under the conditions that mutualauthentication between devices has been established and thatverification and screening is established for an already-issued groupattribute certificate already held by the group attribute certificateissue requesting device.

Further, with an arrangement of the access privilege management methodaccording to the present invention, wherein the group attributecertificate is of a configuration storing link information regarding apublic key certificate corresponding to the group attribute certificate;wherein the access requesting device is of a configuration whereinverification of the public key certificate obtained by the linkinformation is also executed at the time of performing verification ofthe group attribute certificate.

Further, a ninth aspect of the present invention is a communicationmanaging method for a communication processing device for executingaccess restriction processing, the method comprising:

a reception step for receiving, from an access requesting device, agroup attribute certificate which has, as stored information, groupidentification information corresponding to a group which is a set ofcertain communication devices or certain users, and also has affixed anelectronic signature of an issuer; and

an access privilege determination processing step for executingverification, by means of signature verification, of the group attributecertificate received from the access requesting device regarding whetheror not there has been tampering, performing screening regarding whetheror not the access requesting device is a device which belongs to anaccess-permitted group based on group identification information storedin the group attribute certificate; and

an access permissible/impermissible determination step for executingdetermination regarding whether or not access can be permitted, based onthe access privilege determination processing results.

Further, with an arrangement of the communication managing methodaccording to the present invention, the access privilege determinationprocessing step includes a step performing screening regarding whetheror not the access requesting device is an end entity belonging to anaccess-permitted group, based on a group attribute certificate issued tothe end entity which is an access executing device at the accessrequesting device.

Further, with an arrangement of the communication managing methodaccording to the present invention, the access privilege determinationprocessing step includes a step for performing screening regardingwhether or not the access requesting device is a device owned by a userbelonging to an access-permitted group, based on a group attributecertificate issued to a user identification device which is anindividual identification device making up the access requesting device.

Further, an arrangement of the communication managing method accordingto the present invention further comprises an authentication processingstep for executing mutual authentication with the access requestingdevice; wherein, in the access privilege determination processing step,signature verification of the group attribute certificate presented fromthe access requesting device, and screening regarding whether or not thedevice belongs to an access-permitted group, are executed, under thecondition that mutual authentication has been established.

Further, with an arrangement of the communication managing methodaccording to the present invention, the group attribute certificate isof a configuration storing link information regarding a public keycertificate corresponding to the group attribute certificate; and, inthe access privilege determination processing step, verification of thepublic key certificate obtained by the link information is also executedat the time of performing verification of the group attributecertificate.

Further, a tenth aspect of the present invention is a computer programfor effecting execution of a communication managing method for acommunication processing device for executing access restrictionprocessing, the program comprising:

a reception step for receiving, from an access requesting device, agroup attribute certificate which has, as stored information, groupidentification information corresponding to a group which is a set ofcertain communication devices or certain users, and also has affixed anelectronic signature of an issuer; and

an access privilege determination processing step for executingverification, by means of signature verification, of the group attributecertificate received from the access requesting device regarding whetheror not there has been tampering, performing screening regarding whetheror not the access requesting device is a device which belongs to anaccess-permitted group based on group identification information storedin the group attribute certificate; and

an access permissible/impermissible determination step for executingdetermination regarding whether or not access can be permitted, based onthe access privilege determination processing results.

Further, an eleventh aspect of the present invention is a dataprocessing system for executing data processing accompanied by datacommunication processing, between a plurality of devices capable ofmutual communication, wherein, of the plurality of devices, a dataprocessing requesting device, which requests data processing to theother device with which communication is being made, holds a groupattribute certificate which has, as stored information, groupidentification information corresponding to a group which is a set ofcertain devices or certain users, and also has affixed an electronicsignature of an issuer, and transmits the group attribute certificate toa data processing requested device at the time of data processingrequesting processing;

and wherein the data processing requested device executes verificationprocessing of the received group attribute certificate, determineswhether or not the data processing requesting device has data processingrequesting privileges based on the verification, and executes dataprocessing based on determination of privileges.

Further, with an arrangement of the data processing system according tothe present invention, the group attribute certificate stored in thedata processing requesting device has as the issuer thereof the dataprocessing requested device, and has affixed the electronic signature ofthe data processing requested device; wherein the data processingrequested device is of a configuration for executing electronicsignature verification processing applying a public key of itself, asverification processing of the received group attribute certificate.

Further, with an arrangement of the data processing system according tothe present invention, all of the mutually communicable plurality ofdevices are devices which mutually request data processing of the otherdevice with which communication is being made, with each of the deviceshaving a configuration storing the group attribute certificate issued bythe communication party device and transmitting the group attributecertificate stored in itself at the time of data processing requestingof the other device with which communication is being made, and underthe condition of verification being established at the receiving device,processing corresponding to the data processing request is mutuallyexecuted.

Further, with an arrangement of the data processing system according tothe present invention, all of the mutually communicable plurality ofdevices have security chips with anti-tampering configurations, withmutual authentication being executed between the mutual security chipsat the time of data processing requesting of the other device with whichcommunication is being made, and wherein, under the condition thatmutual authentication has been established, the transmission of groupattribute certificates between the devices, and verification of thetransmitted group attribute certificates, is executed.

Further, with an arrangement of the data processing system according tothe present invention, the group attribute certificate stored in thedata processing requesting device has as the issuer thereof the dataprocessing requested device; and issuing processing is performed underthe condition that mutual authentication has been established betweenthe data processing requesting device and the data processing requesteddevice.

Further, with an arrangement of the data processing system according tothe present invention, of the mutually communicable plurality ofdevices, at least one or more devices comprise, as a deviceconfiguration, an end entity for executing communication processing withother device and data processing, and a user identification devicehaving individual identification functions capable of exchanging datawith the end entity; and, in the event that the group attributecertificate is issued to members making up a certain user group, issuingprocessing is carried out under the condition that mutual authenticationis established between the user identification device and a groupattribute certificate issuing processing executing device.

Further, with an arrangement of the data processing system according tothe present invention, of the mutually communicable plurality ofdevices, one is a maintenance executing device for executing maintenanceprocessing for devices, and the other devices are service receivingdevice which receive the maintenance service from the maintenanceexecuting device; wherein the service receiving device stores a serviceattribute certificate which is a group attribute certificate issued bythe maintenance executing device; the maintenance executing devicestores a control attribute certificate which is a group attributecertificate issued by the service receiving device; the serviceattribute certificate is applied for verification at the maintenanceexecuting device that the service receiving device belongs to a group ofdevices or users having maintenance service receiving privileges; andthe control attribute certificate is applied for verification at theservice receiving device that the maintenance executing device belongsto a group of devices or users having maintenance service executingprivileges.

Further, with an arrangement of the data processing system according tothe present invention, a maintenance program executed at the servicereceiving device is transmitted to or stored in the service receivingdevice as an enciphered maintenance program; and the service receivingdevice is of a configuration for deciphering the enciphered maintenanceprogram within a security chip having an anti-tampering configuration,and then executing on the service receiving device.

Further, with an arrangement of the data processing system according tothe present invention, maintenance processing executed at the servicereceiving device is executed based on commands transmitted from themaintenance executing device to the service receiving device; and theservice receiving device transmits a response to the maintenanceexecuting device for the execution results of the commands, and themaintenance executing device executes transmission of new commands tothe service receiving device based on the transmitted response.

Further, a twelfth aspect of the present invention is a data processingdevice for executing data processing based on data processing requestsfrom a data processing requesting device, the data processing devicecomprising:

a data reception unit for receiving from the data processing requestingdevice a group attribute certificate which has, as stored information,group identification information corresponding to a group which is a setof certain devices or certain users and also has affixed an electronicsignature of an issuer;

a privilege determining processing unit for executing verificationprocessing of the received group attribute certificate, and determiningwhether or not the data processing requesting device has data processingrequesting privileges based on the verification; and

a data processing unit for executing data processing based ondetermination of privileges.

Further, with an arrangement of the data processing device according tothe present invention, the privilege determining processing unit is of aconfiguration for executing electronic signature verification processingapplying a public key of itself, as verification processing of thereceived group attribute certificate.

Further, with an arrangement of the data processing device according tothe present invention, the data processing device has a security chipwith an anti-tampering configuration and comprising an encipheringprocessing unit; and the enciphering processing unit has a configurationwherein mutual authentication is executed with the data processingrequesting device in response to a data processing request from the dataprocessing requesting device; wherein the privilege determiningprocessing unit is of a configuration for executing verification of thegroup attribute certificate, under the condition that mutualauthentication has been established.

Further, with an arrangement of the data processing device according tothe present invention, the data processing device is of a configurationcomprising an attribute certificate generating processing unit havingfunctions for generating a group attribute certificate which has, asstored information, group identification information corresponding to agroup which is a set of certain devices or certain users, and also hasaffixed an electronic signature.

Further, a thirteenth aspect of the present invention is a dataprocessing method for executing data processing accompanied by datacommunication processing, between a plurality of devices capable ofmutual communication, wherein, of the plurality of devices, a dataprocessing requesting device, which requests data processing to theother device with which communication is being made, executes a step fortransmitting, to the other device with which communication is being madeat the time of data processing requesting processing, a group attributecertificate which has, as stored information, group identificationinformation corresponding to a group which is a set of certain devicesor certain users, and also has affixed an electronic signature of anissuer;

wherein the data processing requested device executes:

a verification processing step for the received group attributecertificate;

a step for determining whether or not the data processing requestingdevice has data processing requesting privileges based on theverification; and

a step for executing data processing based on determination ofprivileges.

Further, with an arrangement of the data processing method according tothe present invention, the group attribute certificate stored in thedata processing requesting device has as the issuer thereof the dataprocessing requested device, and has affixed the electronic signature ofthe data processing requested device; and, in the verificationprocessing step at the data processing requested device, electronicsignature verification processing applying a public key of itself isexecuted, as verification processing of the received group attributecertificate.

Further, with an arrangement of the data processing method according tothe present invention, all of the mutually communicable plurality ofdevices are devices which mutually request data processing of the otherdevice with which communication is being made, with each of the deviceshaving a configuration storing the group attribute certificate issued bythe communication party device and transmitting the group attributecertificate stored in itself at the time of data processing requestingof the other device with which communication is being made, and underthe condition of verification being established at the receiving device,processing corresponding to the data processing request is mutuallyexecuted.

Further, with an arrangement of the data processing method according tothe present invention, all of the mutually communicable plurality ofdevices have security chips with anti-tampering configurations, withmutual authentication being executed between the mutual security chipsat the time of data processing requesting of the other device with whichcommunication is being made, and wherein, under the condition thatmutual authentication has been established, the transmission of groupattribute certificates between the devices, and verification of thetransmitted group attribute certificates, is executed.

Further, an arrangement of the data processing method according to thepresent invention further comprises an issuing processing step for thegroup attribute certificate stored in the data processing requestingdevice; the issuing processing step being executed under the conditionthat mutual authentication has been established between the dataprocessing requesting device and the data processing requested device.

Further, an arrangement of the data processing method according to thepresent invention further comprises an issuing processing step for thegroup attribute certificate stored in the data processing requestingdevice; wherein, in the event that the group attribute certificate isissued to members making up a certain user group, the issuing processingstep is executed under the condition that mutual authentication isestablished with a user identification device having individualidentification functions making of the data processing requestingdevice.

Further, with an arrangement of the data processing method according tothe present invention, of the mutually communicable plurality ofdevices, one is a maintenance executing device for executing maintenanceprocessing for devices, and wherein the other devices are servicereceiving device which receive the maintenance service from themaintenance executing device, the method comprising: a step for theservice receiving device to transmit to the maintenance executing devicea service attribute certificate which is a group attribute certificateissued by the maintenance executing device; a service attributecertificate verification step for the maintenance executing device toexecute verification of the received service attribute certificate; astep for the maintenance executing device to transmit to the servicereceiving device a control attribute certificate which is a groupattribute certificate issued by the service receiving device; a controlattribute certificate verification step for the service receiving deviceto execute verification of the control attribute certificate; and amaintenance processing step for executing maintenance processing underthe condition that both verification of the service attributecertificate verification and the control attribute certificateverification have been established.

Further, with an arrangement of the data processing method according tothe present invention, a maintenance program executed at the servicereceiving device is transmitted to or stored in the service receivingdevice as an enciphered maintenance program; and the service receivingdevice is of a configuration for deciphering the enciphered maintenanceprogram within a security chip having an anti-tampering configuration,and then executing on the service receiving device.

Further, with an arrangement of the data processing method according tothe present invention, maintenance processing executed at the servicereceiving device is executed based on commands transmitted from themaintenance executing device to the service receiving device; and theservice receiving device transmits a response to the maintenanceexecuting device for the execution results of the commands, and themaintenance executing device executes transmission of new commands tothe service receiving device based on the transmitted response.

Further, a fourteenth aspect of the present invention is a dataprocessing method for executing data processing based on data processingrequests from a data processing requesting device, the methodcomprising:

a data reception step for receiving from the data processing requestingdevice a group attribute certificate which has, as stored information,group identification information corresponding to a group which is a setof certain devices or certain users and also has affixed an electronicsignature of an issuer;

a privilege determining processing step for executing verificationprocessing of the received group attribute certificate, and determiningwhether or not the data processing requesting device has data processingrequesting privileges based on the verification; and

a data processing step for executing data processing based ondetermination of privileges.

Further, with an arrangement of the data processing method according tothe present invention, the privilege determining processing stepincludes a step for executing electronic signature verificationprocessing applying a public key of itself, as verification processingof the received group attribute certificate.

Further, an arrangement of the data processing method according to thepresent invention further comprises a step for executing mutualauthentication with the data processing requesting device in response toa data processing request from the data processing requesting device;and the privilege determining processing step executes verification ofthe group attribute certificate, under the condition that mutualauthentication has been established.

Further, a fifteenth aspect of the present invention is a computerprogram for effecting execution of data processing based on dataprocessing requests from a data processing requesting device, theprogram comprising:

a data reception step for receiving from the data processing requestingdevice a group attribute certificate which has, as stored information,group identification information corresponding to a group which is a setof certain devices or certain users and also has affixed an electronicsignature of an issuer;

a privilege determining processing step for executing verificationprocessing of the received group attribute certificate, and determiningwhether or not the data processing requesting device has data processingrequesting privileges based on the verification; and

a data processing step for executing data processing based ondetermination of privileges.

According to the configuration of the present invention, a groupattribute certificate which has, as stored information, groupidentification information corresponding to a group which is a set ofcertain devices or certain users, and also has affixed an electronicsignature of an issuer, is issued to a service reception entity, andverification is performed by means of signature verification for of thegroup attribute certificate presented from the user device regardingwhether or not there has been tampering, screening is performedregarding whether or not this is a service-permitted group based ongroup identification information stored in the group attributecertificate, and determination is made regarding whether or not servicecan be provided, based on the screening; accordingly, centralizedprivilege confirmation corresponding to various user sets or device setscan be made, so management of individual privilege information can beomitted, thereby enabling effective privilege management.

Further, according to the configuration of the present invention,determining processing regarding whether or not service can be providedis enabled applying a group information database wherein a groupidentifier and permitted service information for members belonging tothe group are correlated, thereby enabling detailed differentiation ofsetting privileges for each group.

Further, according to the configuration of the present invention,screening regarding whether or not the object of service permission isexecuted for each of a plurality of sets of different groupidentification information obtained from a plurality of group attributecertificates based on a plurality of different group definitionspresented by the user device, and determining processing regardingwhether or not service can be provided can be executed under thecondition that all group identification sets are the object of servicepermission, thereby enabling various arrangements of privilege settings,such as providing services based on multiple conditions such as a groupset corresponding to devices and a group set for users, and so forth.

Further, according to the configuration of the present invention, basedon group identification information stored in a group attributecertificate which has, as stored information, group identificationinformation corresponding to a group which is a set of certaincommunication devices or certain users, and also has affixed anelectronic signature of an issuer, screening is performed regardingwhether or not the access requesting device is a device which belongs toan access-permitted group, and determination regarding whether or notaccess can be permitted is made based on the screening, therebypermitting access only to an access requesting communication processingdevice group which are users or user devices which are a member of agroup arbitrarily set by users having communication processing devices.

Further, according to the configuration of the present invention,screening is performed regarding whether or not the access requestingdevice is a device owned by a user belonging to an access-permittedgroup, based on a group attribute certificate issued to a useridentification device which is an individual identification devicemaking up the access requesting device, and determination is maderegarding whether or not access can be permitted, based on thescreening, so even in the event that the communication processing devicehas been changed, access is permitted in the screening based on thegroup attribute certificate issued to the user identification devicewhich is the individual identification device, and cases wherein accessis forbidden due to changing the communication processing device can beprevented.

Further, according to the configuration of the present invention, a dataprocessing requesting device, which requests data processing to theother device with which communication is being made, transmits to a dataprocessing requested device a group attribute certificate which has, asstored information, group identification information corresponding to agroup which is a set of certain devices or certain users, and also hasaffixed an electronic signature of an issuer, verification processing ofthe received group attribute certificate is performed at the dataprocessing requested device, determination is made regarding whether ornot the data processing requesting device has data processing requestingprivileges based on the verification, and data processing is performedbased on determination of privileges, so cases wherein processing isexecuted by a wrong device or user is prevented, and proper dataprocessing based on valid privileges is carried out.

Further, according to the configuration of the present invention, withan arrangement wherein a plurality of data processing devices requestdata processing of the other device with which communication is beingmade, thereby collaboratively executing data processing, each of thedevices transmits the group attribute certificate stored in itself atthe time of data processing requesting of the other device with whichcommunication is being made, and under the condition of verificationbeing established at the receiving device, processing corresponding tothe data processing request is mutually executed, thereby enablingproper collaborative data processing accompanying communication betweenthe plurality of data processing devices.

Further, according to the configuration of the present invention, amaintenance executing device and a maintenance service receiving deviceeach store a control attribute certificate and a service attributecertificate, with the attribute certificates being exchanged at the timeof executing maintenance service, and mutually verified and screened ateach device, wherein maintenance processing is performed under thecondition that verification has been established, so maintenanceprocessing can be realized in a sure manner within the set privilegeranges of each.

Note that the computer program according to the present invention isprogram code which can be provided to computer systems capable ofexecuting various types of computer code for example, in acomputer-readable format by storage media or communication media, forexample, storage media such as CDs, FDs, MOs, and the like, orcommunication media such as a network or the like. Providing such aprogram in a computer-readable format realizes processing correspondingto the program on the computer system.

Further objects, features, and advantages of the present invention willbecome apparent from detailed description based on the later-describedembodiments of the present invention and the appended drawings. Notethat the term “system” in the present specification means a logicalgroup configuration of multiple devices, and is not restricted to thecomponent devices being within a single housing.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram describing the public key infrastructure andprivilege management infrastructure in a privilege management system.

FIG. 2 is a diagram illustrating the format of a public key certificate.

FIG. 3 is a diagram illustrating the format of a public key certificate.

FIG. 4 is a diagram illustrating the format of a public key certificate.

FIG. 5 is a diagram illustrating the format of an attribute certificateas a privilege information certificate.

FIG. 6 is a diagram illustrating a configuration example of an issuer,holder, verifier, and attribute information, of a group attributecertificate (group AC).

FIG. 7 is a diagram illustrating an issuing policy table of a groupattribute certificate.

FIG. 8 is a diagram illustrating a trust model for describing the trustrelation configuration of the entities participating in a privilegemanagement system.

FIG. 9 is a diagram illustrating a configuration example of a securitychip configured at an end entity (EE) and user identification device(UID) as user devices.

FIG. 10 is a diagram illustrating an example of stored data of thesecurity chip of a user device.

FIG. 11 is a diagram describing a schematic flow of issuing application,issuing processing, and usage processing, of a group attributecertificate.

FIG. 12 is a diagram describing group information sharing processingbetween a service provider (SP) and an attribute authority (AA) orattribute registration authority (ARA).

FIG. 13 is a diagram illustrating a handshake protocol (TLS 1.0) whichis one authentication method for the public key encryption method.

FIG. 14 is a diagram illustrating the generating configuration of MAC(Message Authentication Code).

FIG. 15 is a diagram illustrating an information configuration exampleof an issuing policy table and a group information database.

FIG. 16 is a diagram illustrating a processing sequence in the eventthat the security chip (SC) of the end entity (EE) which is a userdevice is the issue requesting entity for the group attributecertificate.

FIG. 17 is a flowchart describing the processing for generating anelectronic signature.

FIG. 18 is a flowchart describing the processing for verifying anelectronic signature.

FIG. 19 is a sequence diagram describing the procedures for issuing agroup attribute certificate corresponding to a user security chip (USC)within a user identification device (UID).

FIG. 20 is a sequence diagram describing the processing up to startingservice usage privilege configuration, using a group attributecertificate.

FIG. 21 is a diagram describing the relation between a public keycertificate (PCK) and attribute certificate (AC).

FIG. 22 is a diagram illustrating the verification processing flow foran attribute certificate (AC).

FIG. 23 is a diagram illustrating the verification processing flow for apublic key certificate (PKC).

FIG. 24 is a sequence diagram describing the processing up to startingservices including service usage privilege confirmation, using a groupattribute certificate.

FIG. 25 is a sequence diagram describing the screening processing for agroup attribute certificate (Gp. AC).

FIG. 26 is a diagram describing the concept of a case wherein a user oruser device belonging to multiple different groups is a condition forproviding services.

FIG. 27 is a sequence diagram describing the processing up to providingservice based on the group attribute certificate issued corresponding tothe user security chip (USC) within the user identification device(UID).

FIG. 28 is a sequence diagram describing the processing up to providingservice based on the group attribute certificate issued corresponding tothe user security chip (USC) within the user identification device(UID).

FIG. 29 is a sequence diagram describing the processing for issuing agroup attribute certificate between user devices, and storing the groupattribute certificate.

FIG. 30 is a diagram describing the processing sequence for issuing agroup attribute certificate having access permission information as anattribute.

FIG. 31 is a diagram describing an example of correlation between agroup attribute certificate having access permission information asgroup information, and another group attribute certificate.

FIG. 32 is a diagram describing a processing sequence for an accessrequested user device to commission attribute certificate issuingprocessing to another user device instead of executing the attributecertificate issuing processing itself.

FIG. 33 is a diagram describing a service usage sequence accompanyingaccess permissible/impermissible determination processing using a groupattribute certificate defining access permission information as groupinformation.

FIG. 34 is a diagram illustrating an example of a group attributecertificate used for services.

FIG. 35 is a sequence diagram describing the processing for issuing asecond group attribute certificate B including content usage permissioninformation as group information, based on a first group attributecertificate A.

FIG. 36 is a sequence diagram describing processing for presenting thesecond group attribute certificate B to a service provider, confirmingcontent usage privileges, and receiving provision of services, i.e.,content distribution services.

FIG. 37 is a diagram describing examples of attribute certificates to beapplied to processing wherein multiple different attribute certificatesare applied to conform the content usage privilege of a user or userdevice, and provide services.

FIG. 38 is a flowchart describing content usage privilege confirmationapplying different group attribute certificates, and service providingprocessing.

FIG. 39 is a diagram illustrating a combination table data configurationexample of group attribute certificates set as service providingconditions.

FIG. 40 is a diagram describing usage privilege confirmation processingapplying multiple group attribute certificates.

FIG. 41 is a diagram illustrating an example of a group attributecertificate to be applied in medical processing.

FIG. 42 is a diagram describing an attribute certificate stored invarious devices in a remote control system which performs medicalprocessing.

FIG. 43 is a diagram describing a processing sequence for performingusage privilege confirmation processing of a medical diagnosis programexecution service, applying a group attribute certificate stored in auser identification device, and starting the service.

FIG. 44 is a diagram describing a processing sequence for performingusage privilege confirmation processing of a diagnosis data handlingprocessing service for the execution results of a medical diagnosisprogram, applying a group attribute certificate, and starting theservice.

FIG. 45 is a diagram illustrating a group attribute certificate to beapplied to remote maintenance processing.

FIG. 46 is a diagram describing an attribute certificate stored in eachdevice in a system which performs maintenance services.

FIG. 47 is a diagram describing a usage arrangement of a serviceattribute certificate and a control attribute certificate at the time ofexecuting service.

FIG. 48 is a sequence diagram describing service processing such asmaintenance or the like, applying the service attribute certificatestored in a home appliance (EE) and a control attribute certificatestored in the service provider.

FIG. 49 is a diagram describing screening processing of the serviceattribute certificate.

FIG. 50 is a diagram describing a service based on a control attributecertificate, e.g., a sequence for executing maintenance processing for ahome appliance, for example.

FIG. 51 is a diagram describing an example of processing fortransmitting a maintenance execution program from a manufacturer sidedevice (SP) to a user side home appliance (EE).

FIG. 52 is a diagram describing an example of processing forconsecutively transmitting commands from a maintenance execution programfrom a manufacturer side device (SP) to a user side home appliance (EE),receiving responses based on execution of the commands from the homeappliance (EE), and responding to the responses.

FIG. 53 is a diagram describing an example of processing for providing aservice attribute certificate and control attribute certificate to themanufacturer side (SP) at the time of requesting providing of a service.

FIG. 54 is a diagram describing an example of a group attributecertificate applied in a communication service.

FIG. 55 is a diagram describing an storage configuration example of agroup attribute certificate applied in a communication service.

FIG. 56 is a diagram describing a processing sequence for performingusage privilege confirmation processing of a chat room participationservice applying a group attribute certificate, and starting theservice.

FIG. 57 is a diagram describing a processing sequence for performingaccess privilege confirmation processing applying a group attributecertificate, and starting communication.

FIG. 58 is a diagram describing the overview of an execution attributecertificate.

FIG. 59 is a flowchart describing the overview of usage procedures foran execution attribute certificate.

FIG. 60 is a diagram describing the issuing sequence for an executionattribute certificate.

FIG. 61 is a diagram describing the issuing sequence for an executionattribute certificate.

FIG. 62 is a diagram illustrating a configuration example of anexecution AC table.

FIG. 63 is a diagram describing the processing for generating aregistration key generating execution AC at a security module (SM).

FIG. 64 is a diagram describing the processing for generating aregistration key, based on the registration key generating execution ACexecuted at a security chip.

FIG. 65 is a diagram describing the processing for generating a serviceproviding execution AC at a security module (SM).

FIG. 66 is a diagram showing an application sequence of a serviceproviding execution AC at the user device side.

FIG. 67 is a diagram describing the processing details in serviceproviding processing at a security chip (SC).

FIG. 68 is a diagram describing security chip (SC) registration keydestruction processing.

FIG. 69 is a diagram describing reset processing which is destructionprocessing of a registration key based on a reset request.

FIG. 70 is a diagram describing execution attribute certificate reset(destruction) processing, wherein an execution attribute certificate isdestroyed under acknowledgement of a service provider (SP), and theservice provider is notified that the destruction was carried outwithout fail.

FIG. 71 is a diagram describing execution attribute certificate reset(destruction) processing, wherein an execution attribute certificate isdestroyed under acknowledgement of a service provider (SP), and theservice provider is notified that the destruction was carried outwithout fail.

FIG. 72 is a diagram describing the details of reset confirmationresults generating processing.

FIG. 73 is a diagram describing registration key destruction processingbased on an execution AC.

FIG. 74 is a diagram describing processing for applying services,applying a service providing execution attribute certificate, withrestrictions on the number of times, at a user device.

FIG. 75 is a diagram describing processing for applying services,applying a service providing execution attribute certificate, withrestrictions on the number of times, at a user device.

FIG. 76 is a diagram describing processing at a security chip (SC) inthe event that the number of usage times following updating≧1.

FIG. 77 is a diagram describing processing at a security chip (SC) inthe event that the number of usage times following updating=0.

FIG. 78 is a diagram describing processing for applying a serviceproviding execution attribute certificate with transfer functions.

FIG. 79 is a diagram describing processing details following decipheringprocessing of the service providing execution attribute certificate withtransfer functions.

FIG. 80 is a diagram describing processing details following decipheringprocessing of the service providing execution attribute certificate withtransfer functions.

FIG. 81 is a diagram describing enciphered data deciphering processing,applying a service providing execution attribute certificate withtransfer functions.

FIG. 82 is a diagram describing the overview of a screening proxyexecution attribute certificate.

FIG. 83 is a diagram describing processing applying a screening proxyexecution attribute certificate.

FIG. 84 is a diagram describing processing for generating and issuing ascreening proxy group attribute certificate.

FIG. 85 is a diagram describing processing for inputting a screeningproxy execution attribute certificate and generating a screening proxygroup attribute certificate.

FIG. 86 is a diagram describing the overview of an allograph executionattribute certificate.

FIG. 87 is a diagram describing processing applying an allographexecution attribute certificate.

FIG. 88 is a diagram describing processing executed at the time of apresentation request for an allograph group attribute certificate from averifier such as a service provider (SP) or the like.

FIG. 89 is a diagram illustrating a configuration example of aninformation processing device of the entities such as a user device,service provider, and so forth.

BEST MODE FOR CARRYING OUT THE INVENTION

The following is a detailed description of the present invention withreference to the drawings. Note that the description will proceed inorder of the items described below.

(1) Privilege management system configuration overview

(2) User device configuration

(3) Group attribute certificate issuing and usage processing

(3-1) Preparation processing before issuing group attribute certificate

(3-2) Group attribute certificate issuing processing

(3-3) Group attribute certificate usage processing

(4) Issuing and usage processing of group attribute certificates betweenuser devices

(5) Specific usage examples of group attribute certificate

(5-1) Content distribution service

(5-2) Remote control service

(5-3) Remote maintenance service

(5-4) Personal communication service

(6) Execution attribute certificate (execution AC)

(6-1) Execution attribute certificate overview

(6-2) Execution attribute certificate issuing processing

(6-3) Execution attribute certificate application processing

(6-4) Registration key resetting processing

(6-5) Execution attribute certificate reset (destruction) processing

(7) Specific usage processing of execution attribute certificate

(7-1) Service providing execution attribute certificate withrestrictions on the number of times

(7-2) Service providing execution attribute certificate with transferfunction

(7-3) Proxy execution attribute certificate

(8) Configuration of entities

[(1) Privilege Management System Configuration Overview]

As shown in FIG. 1, the privilege management system according to thepresent invention has as the basic infrastructure a public keyinfrastructure (PKI) 101 based on public key certificates (PKC) 121, anda privilege management infrastructure (PMI) 102 based on attributecertificates (AC) 122, and has a configuration wherein privilegeconfirmation processing is executed between user devices 111 and 113which have an anti-tampering security chip (or security module) and aservice-provider-side service provider device 112, or between the mutualuser devices 111 and 113, and service providing processing is executedbased on privilege confirmation.

The user devices 111 and 113 are terminals of a user which receivevarious types of content providing services such as music, images,programs, etc., from a service provider 112, as well as otherinformation usage services and payment services and the like, forexample, and specifically, the user devices 111 and 113 are PCs, gameterminals, reproducing devices for DVDs or CDs or the like, portablecommunication terminals PDAs, memory cards, or the like.

Also, the user devices 111 and 113 are terminals capable of mutualcommunication processing between the user devices, and executeprocessing regarding whether or not access can be made to the userdevices based on privilege confirmation. A user device is provided witha security chip having an anti-tampering configuration. The details ofuser devices will be described later.

The service provider 112 is a service provider which performs providingof various services to the user devices 111 and 113 having the securitychips, such as contents providing, payment processing, and so forth.While FIG. 1 only shows two user devices and one service provider, thereare a great number of user devices and service providers under theinfrastructures of the public key infrastructure (PKI) 101 and theprivilege management infrastructure (PMI) 102, with each executingservice providing based on privilege confirmation. Note that service isnot only provided from service providers to user devices, but alsoservices are provided mutually between user devices.

(Public Key Certificate: PKC)

Next, the public key infrastructure will be described. The public keyinfrastructure (PKI) 101 is an infrastructure enabling execution ofauthentication processing between communicating entities, enciphermentprocessing of transfer data, etc., applying public key certificates(PKC). Description will be made regarding public key certificates (PKC)with reference to FIG. 2, FIG. 3, and FIG. 4. A public key certificatesis a certificate issued by a certification authority (CA), and is acertificate created by a user or entity presenting own ID, public key,etc., to the certification authority, and the certification authorityside adding the ID of the certification authority, the period ofvalidity, etc, and further attaching a signature of the certificationauthority.

Now, it has become commonplace to provide a registration authority (RA)as an agent for the certification authority (CA), with a configurationwherein public key certificate (PKC) issuing applications are accepted,applicants are screened, and management is performed, at theregistration authority (RA).

FIG. 2 through FIG. 4 show an example of a public key certificateformat. This is an example compliant with public key certificate formatITU-T X.509.

Version indicates the version of the certificate format.

Serial Number is the serial number of the public key certificate set bythe certification authority (CA) of the public key certificate.

Signature is a signature algorithm of the certificate. Note that thereare elliptic curve encryption and RSA for signature algorithms, and inthe event that elliptic curve encryption is applied, parameter and keylength are recorded, and in the event that RSA is applied, key length isrecorded.

Issuer is a field where the name of the issuer of the public keycertificate, i.e., the name of the public key certificate issuingauthority (IA) is recorded in an identifiable format (DistinguishedName).

Validity records the date and time of starting and the date and time ofending, as the valid period of the certificate.

Subject Public Key Information stores the algorithm of the key and thekey as public key information of the certificate holder.

Authority Key Identifier (Key Identifier, Authority Cert Issuer,Authority Cert Serial Number) is information for identifying the key ofthe certificate issuer used for signature verification, and stores thekey identifier, name of the authority certificate issuer, and authoritycertificate serial number.

Subject Key Identifier stores identifiers for identifying the keys inthe event of authenticating multiple keys in a public key certificate.

Key Usage is a field for specifying the purpose of use of the key, withthe following usage purposes being specified: (0) for digital signature,(1) for denial prevention, (2) for key encryption, (3) for messageencipherment, (4) for sending shared key, (g) for signature confirmationin authentication, and (6) for signature confirmation in revocationlist.

Private Key Usage Period records the valid period of the secret keycorresponding to the public key stored in the certificate.

Certificate Policy records the certificate issuing policies of thepublic key certificate issuer. An example is policy ID andauthentication standards compliant to ISO/IEC 9384-1.

Policy Mapping is a field for storing information relating torestrictions relating to policies in the authentication path, and isnecessary only for the certification authority (CA) certificate.

Subject Alt Name is a field for recording an alternative name for acertificate holder.

Issuer Alt Name is a field for recording an alternative name for thecertificate issuer.

Subject Directory Attribute is a field for recording attributes of adirectory necessary for the certificate holder.

Basic Constraint is a field for distinguishing whether the public key tobe proved is for a certification authority (CA) signature or thecertificate holder.

Permitted Subtree Constraint Name (Name Constraints Permitted Subtrees)is a field storing restriction information of the name of thecertificate issued by the issuer.

Constraint Policy (Policy Constraints) is a field for storingrestriction information relating to policies in the authentication path.

CRL Reference Point (Certificate Revocation List Distribution Points) isa field for describing reference points of a revocation list, forconfirming whether or not the certificate is invalid, at the time of thecertificate holder using the certificate.

Signature Algorithm is a field storing an algorithm used for signing acertificate.

Signature is a signature field of the public key certificate issuer. Anelectronic signature is data generated by generating a hash valueapplying a hash function to the entire certificate, and using the secretkey of the issuer with regard to the hash value. While removing thesignature and hash will enable tampering, if this can be detected, theeffects are essentially the same as being tamper-proof.

The certification authority issues the public key certificate shown inFIG. 2 through FIG. 4, updates public key certificates of which thevalid period has expired, and creates, manages, and distributes arevocation list for rejecting users which have engaged in unauthorizedactivities. Also, public keys and secret keys are generated asnecessary.

On the other hand, at the time of using the public key certificate, theuser uses the public key of the certification authority which the userhimself/herself holds, to verity the electronic signature of the publickey certificate, extracts the public key from the public key certificatefollowing successfully verifying the electronic signature, and uses thepublic key. Accordingly, all users using the public key certificate needto hold a common certification authority public key.

(Attribute Certificate)

The Privilege Management Infrastructure (PMI) 102 is an infrastructurewhich enables execution of privilege confirmation processing applyingthe attribute certificate (AC) 122. A group attribute certificate (groupAC), which is a form of an attribute certificate, will be described withreference to FIG. 5 through FIG. 7. The functions of an attributecertificate are confirmation functions of service usage privileges, withprivilege-related information such as usage privileges of contents andservices of a service provider for example, and attribute information ofthe holder relating to privileges, are described in the attributecertificate.

An attribute certificate is a certificate basically issued by anattribute authority (AA), which stores attribute information with regardto certificate issuance, created by the attribute authority sideattaching information such as ID and valid period and the like, andfurther attaching a signature with the secret key of the attributeauthority. Note, however, that in the following description, groupattribute certificates and execution attribute certificates are notnecessarily restricted to an attribute authority (AA) as the issuingauthority thereof, and that issuing processing can be made at a serviceprovider or user device.

Providing an attribute registration authority (ARA) as an agent for theattribute authority (AA) and performing attribute certificate (AC)issuing application reception, screening of applicants, and management,allows the processing load to be dispersed.

The group attribute certificate (group AC) applied in the configurationof the present invention is an attribute certificate wherein multipleobjects, such as multiple users or multiple user devices are set as onegroup as a set with the same attributes, and is issued to the devices orusers making up the group with the set group as a unit. A groupattribute certificate holds a stored information group identificationinformation set corresponding to the group made up of certain devices orcertain users, and also has the electronic signature of the issuerattached thereto.

This is issued to users or user devices having an attribute of acompany, organization, school, or the like, to which multiple peoplebelong, or belonging to a group such as a family. Or, this is issued tomembers (users, user devices) of a group which is a unit of multipleusers which receive services provided by a single service provider.Various settings can be made regarding groups, and specific exampleswill be described later.

Now, an execution attribute certificate which will be described later onholds as stored data encipherment execution commands including dataprocessing commands subjected to encipherment processing, and address(Ad) information indicating the storage region in the user device memoryfor the registration key applied for decipherment processing of theenciphered execution commands. Details of the execution attributecertificate will be described later.

The basic format of the attribute certificate is stipulated by ITU-TX.509, and a profile is established with IETF PKIX WG. Unlike a publickey certificate, this does not include the public key of the holder.However, the signature of the attribute certificate authority isattached, and accordingly is the same as the public key certificate inthat determination regarding whether or not there has been tampering canbe made by verifying this signature.

Also note that the group attribute certificate or execution attributecertificate applied in the present invention can be configured compliantto the basic format of the attribute certificate. However, following theformat stipulated by ITU-T X.509 is not indispensable, and an originalformat may be used to configure the attribute certificate.

With the configuration of the present invention, the functions of theattribute certificate authority (AA) which issues and manages attributecertificates (AC), and of the attribute registration authority (ARA),can be handled by the service provider or user device. Of course, theservice provider or user device itself can be configured to function asan attribute certificate authority (AA) or attribute registrationauthority (ARA).

An attribute certificate is basically used in connection with a publickey certificate. That is to say, whether the attribute certificateholder is the real person or not is confirmed with the public keycertificate, and further, what sort of privileges are provided to theholder is confirmed. For example, at the time of a service providerproviding services to a user or a user device, whether the user or userdevice has the privilege to receive the service is confirmed byverifying the attribute certificate. At the time of verification of theattribute certificate, following signature verification of thecertificate, verification of the public key certificate correlated withthe attribute certificate is also performed.

At this time, as a rule, the certificate chain is preferably tracked tothe highest order public key certificate and verified in order. With ancertification authority configuration wherein multiple certificationauthorities (CA) exist in a hierarchical arrangement, a public keycertificate of a lower-order certification authority itself is signed bya higher order certification authority issuing the public keycertificate. That is to say, there is a chain public key certificateissuing configuration wherein a higher-level certification authority(CA-High) issues public key certificates to a lower certificationauthority (CA-Low). Chain verification of public key certificates meanstracking the certificate chain from bottom to top so as to obtain thechain information up to the highest-order public key certificate,thereby performing signature verification of public key certificates upto the highest order (root CA).

Not performing revocation processing can be realized by making the validperiod of the attribute certificate to be short. In this case,revocation procedures of the certificate and reference procedures ofrevocation information and the like can be omitted, which isadvantageous in that the system is simplified. However, some sort ofmeasures must be taken regarding unauthorized use of certificates, sosufficient caution is necessary.

The configuration of the group attribute certificate will be describedwith reference to FIG. 5.

The version number of the certificate indicates the version of thecertificate format.

Public Key Certificate Information of AC Holder is information regardingthe public key certificate (PKC) of the issuer of the attributecertificate (AC), and is information of the PKC issuer name, PKC serialnumber, PKC issuer unique ID, and so forth, having functions as linkdata for correlating with a corresponding public key certificate.

Name of Attribute Certificate Issuer is a field where the name of theissuer of the attribute certificate, i.e., the attribute authority (AA)is recorded in an identifiable format (Distinguished Name).

Signature Algorithm Identifier is a field for recording the signaturealgorithm identifier of the attribute certificate.

Valid Period of Certificate records starting date and time, and endingdate and time, which is the valid period of the certificate.

The Attribute Information field stores a group ID as the groupidentification information for identifying the group of the groupattribute certificate. The group ID is an identifier (ID) correspondingto the entry of the service provider (SP) managed group informationdatabase (see lower right space in FIG. 5) possessed by a serviceprovider performing privilege confirmation using this group attributecertificate.

The service provider (SP) managed group information database which theservice provider has is a table correlating, for example, the issuer ofthe group attribute certificate (ARA) and the group identificationinformation as a group identifier (group ID), and group information suchas “employee of company A” and “family member of Mr. B”, as shown thelower right space in FIG. 5. The service provider extracts correspondingentries from the table based on the group identification information(group ID) as certificate-stored data in the privilege confirmationprocessing based on the group certificate, and obtains the groupattribute certificate information including the group information.

Note that various types of information can be stored in the attributeinformation field other than group identification information (groupID), for example, content usage restriction information such as contentusage restrictions and the like, detailed information relating toprivilege such as service usage restriction information and the like,and further, various types of information such as service provideridentifier (ID), service provider name, and so forth. While details willbe described later, this may be also applied as a field for storinginformation necessary for obtaining a content key to be used fordeciphering enciphered contents.

The service provider sends the group attribute certificate to the userdevice, and following verification of the attribute certificate, theuser device stores this in memory of the security chip within itself.

The attribute certificate further stores a signature algorithm, with asignature made by an attribute certificate issuer, such as an attributeauthority (AA), for example. In the event that the issuer is a serviceprovider or a user device, signatures of each issuer are attached. Anelectronic signature is data generated by generating a hash valueapplying a hash function to the entire attribute certificate, and usingthe secret key of the issuer of the attribute certificate with regard tothe hash value.

FIG. 6 shows a configuration example of the issuer, holder, verifier,and attribute information, of a group attribute certificate (group AC).In the event that a group attribute certificate is issued to each ofmultiple user device groups belonging to users in one company or onefamily for example, the issued group attribute certificate is stored inthe security chip (SC) or user security chip (USC) within the deviceowned by the user. Details of user devices will be described later.

A verifier which executes privilege confirmation based on the groupattribute certificate issued to the user device is a security module(SM) within a service provider device for example, which is a serviceproviding entity, or a security chip (SC) within a user device. Notethat the security chip within the user device or the security module inthe service provider device preferably has an anti-tamperingconfiguration wherein external read-out of data is restricted.

A group attribute certificate has, as attribute information, groupidentification information (group ID) serving as identificationinformation, capable of identifying, for example, the one company or theone family.

FIG. 7 illustrates a configuration example of an issuing policy table ofthe group attribute certificate. The group attribute certificate issuingpolicy table is a table managed by an entity issuing the group attributecertificate, such as an attribute certificate authority (AA), anattribute registration authority (ARA) serving as an agent for theattribute certificate authority (AA), or a service provider or userdevice, and is a table wherein the group identification information(group ID) of the issued group attribute certificate, group information,and issuing policy such as issuing standard and the like, arecorrelated. For example, screening is executed based on the issuingpolicy table of the group attribute certificate at the time of newlyissuing, additionally issuing, or updating group attribute certificates,and procedures such as issuing and updating are carried out as long asthe policies are satisfied.

FIG. 8 illustrates a trust model describing the trust relationconfiguration of the entities participating on the privilege managementsystem.

The system holder (SH) 130 is the entity carrying out the centralizedadministration of the entire privilege management system according tothe present invention, i.e., the system operating entity, and ensuresthe legitimacy of the security chips (SC) and security modules (SM) ofthe entities participating in the system, and is responsible of issuingpublic key certificates (PKC). The system holder (SH) 130 comprises aroot CA 131 as the highest-order certification authority, multiplecertification authorities (CA) 132 in a hierarchical configuration, anda registration authority (RA) 133 serving as a public key certificateissuing agent.

The system holder (SH) 130 issues public key certificates (PKC) to theentities, which are the attribute authority (AA) 140, attributeregistration authority (ARA) 150, service provider 160, and useridentification device (UID) 171 and end entity (EE) 172 serving as auser device 170, with each entity storing the public key certificate(PKC) in an external storage device a built-in anti-tamperingconfiguration security chip (SC) or security module (SM), in some cases.

Also, the group attribute certificate (group AC) receives attributecertificate issuing requests from the service provider 160, the useridentification device (UID) 171 and end entity (EE) 172 serving as auser device 170, and so forth, at the attribute registration authority(ARA) 150, performs attribute certificate issuing screening followingthe policy (issuing conditions, etc.) of the policy table 151 describedwith reference to FIG. 7 earlier, and in the event that determination ismade that issuing is permissible, transfers an issuing commission fromthe attribute registration authority (ARA) 150 to the attributeauthority (AA) 140.

The attribute authority (AA) 140 stores the group identificationinformation (group ID) as attribute information based on the groupattribute certificate issuing commission, and issues a group attributecertificate (see FIG. 5) with a signature attached with the secret keyof the attribute authority (AA) 140, to the issuing requester.

As described above, the attribute authority (AA) 140 and the attributeregistration authority (ARA) 150 can be configured so that the serviceprovider or user device carry out the functions thereof.

[(2) User Device Configuration]

Next, the configuration of a user device serving as an informationprocessing device for using services will be described. User devices aredivided into two categories, based on the functions thereof. One is anend entity (EE) serving as a device which actually uses services,examples of which are various types of data processing devices such asPCs, home servers, PDAs and other like portable terminals, IC cards andso forth, having an interface for receiving service information providedby the service provider. These devices have a security chip (SC) ormodule (SM) with an anti-tampering configuration, storing a public keycertificate corresponding to the device, and a group attributecertificate corresponding to the device, as necessary.

The other is a user identification device (UID) applied to individualauthentication processing. The user identification device (UID) is alsoconfigured of a similar devices as the end entity, but is a device whichdoes not necessarily have an interface for directly receiving serviceinformation provided by the service provider. Communication with theservice provided devices is carried out via the end entity (EE). Theuser identification device (UID) is a device applied to userauthentication. These devices have security chips (SC) or secret modules(SM) with anti-tampering configurations, storing public key certificatescorresponding to the device, and group attribute certificatescorresponding to the device, as necessary.

Note that while the end entity (EE) and the user identification device(UID) can be configured as individual devices, a configuration may alsobe made wherein the functions of both are provided to a single device.

As for a specific configuration example, there is a configurationwherein a device such as an IC card for example makes up the useridentification device (UID), and a PC the end entity (EE). With thisconfiguration, the IC card is set in the PC in a state wherein datatransfer can be made, first, communication is made between the IC cardand the service provider via the PC to execute user authentication anduser privilege confirmation processing applying the public keycertificate and the group attribute certificate, and following thisprocessing, processing can be further executed for authentication andprivilege confirmation between the PC service as an end entity and theservice provider. Details of the privilege confirmation processing willbe described later.

Description of an example of the configuration of the security chipincluded in the end entity (EE) and user identification device (UID)serving as a user device will be descried with reference to FIG. 9. Notethat the end entity (EE) is configured of a CPU serving as dataprocessing means, a PC, game terminal, portable terminal, PDA, IC card(memory card), playback or recording/playback device for DVDs or CDs orthe like, having communication functions etc., and has a security chip(SC) with an anti-tampering configuration.

As shown in FIG. 9, the user device 200 made up of the end entity (EE)or user identification device (UID) has a security chip 210 built in soas to be capable of mutually transferring data to a user device controlunit 221.

The security chip 210 comprises a CPU (Central Processing Unit) 201having program execution functions and computation processing functions,and also has a communication interface 202 with data communicationinterface functions, ROM (Read Only Memory) 203 storing various types ofprograms to be executed by the CPU 201, such as encipherment programs,RAM (Random Access Memory) 204 functioning as loading area of theexecution program, work area of processing the programs, an enciphermentprocessing unit 205 for executing authentication processing withexternal devices, generating electronic signatures, verificationprocessing, and encipherment processing including encipherment anddecipherment of stored data, and a memory unit 206 configured of, forexample, EEPROM (Electrically Erasable Programmable ROM), storinginformation for each service provider, and information unique to thedevice, including various types of key data.

The user device 200 comprises an external memory unit 222 configured ofEEPROM or a hard disk or the like, serving as a storage region forstoring enciphered contents or service information of the like. Theexternal memory unit 222 can also be used as a storage region for thepublic key certificate and group attribute certificate.

In the event of a user device having a security chip connecting to anexternal entity such as a service provider for example, and executingdata transfer processing, connection with the service provider isexecuted via a network interface 232. However, as described above, it isthe end entity (EE) which has the interface for executing connectionwith the service provider, and the user identification device (UID) doesnot necessarily have the network interface 232; accordingly, connectionis made to the connecting device interface 231 of the end entity (EE)via the connecting device interface 231 of the user identificationdevice (UID), and communication via the network interface 232 of the endentity is executed.

That is to say, the user identification device (UID) executescommunication with the service provider device via the end entity.

In the event of transferring data between the security chip 210 of theuser device such as the end entity (EE) and user identification device(UID), and the service provider, mutual authentication is preformedbetween the security chip 210 and the external entity, and also thetransferred data is enciphered, as necessary. Details of such processingwill be described later.

FIG. 10 shows an example of stored data in the security chip of the userdevice. Much of this is stored in the memory unit 206 configured ofEEPROM (Electrically Erasable Programmable ROM), such as flash memorywhich is a type of non-volatile memory, but the public key certificate,group attribute certificate, and later-described execution attributecertificate, may be stored in the memory within the security chip or inexternal memory.

The various types of data will be described.

Public key certificate (PKC): A public key certificate is a certificateindicating to a third party that the public key is authentic, and thecertificate includes the public key to be distributed, and an electronicsignature of a reliable certification authority is affixed thereto. Theuser device stores public key certificates necessary for obtainingpublic keys to be applied to authentication, encipherment, deciphermentprocessing, etc., at the time of executing data communication with userdevices, such as a public key certificate of the highest-ordercertification authority (root CA) having the hierarchical configurationdescribed above, a public key certificate of a service provider which isto provide service to the user device, and so forth.

Group attribute certificate (AC): While the public key certificateidentifies the real; person of the certificate user (holder), the groupattribute certificate is for identifying the group of certificate usersand confirming the usage privileges given to members making up thegroup. A user can use services based on the rights and privilegesinformation listed in the group attribute certificate, by presenting thegroup attribute certificate. Note that the group attribute certificateis issued based on predetermined issuing procedures and each entitywhich has received the group attribute certificate stores this withinthe security chip (SC) or security module (SM) having an anti-tamperingconfiguration, or in some cases, in external memory. The details ofissuing and storing processing will be described later.

Execution attribute certificate: This is an attribute certificatehaving, as the stored data thereof, enciphered execution commandsincluding data processing executing commands subjected to enciphermentprocessing, and address (Ad) information indicating the storage regionwithin the memory of the user device where the registration key to beapplied for the deciphering processing of the enciphered executioncommands is; whereby various types of services are executed by obtainingexecuting commands by deciphering the enciphered execution commands byapplying the registration key obtained from the memory within the userdevice based on the address information, and executing the executioncommands. The details of such processing will be described later.

Key data: Key data stored includes public key and secret key pairs setfor the security chip, registration keys applied at the time ofdeciphering enciphered execution commands stored in the executionattribute certificate described above, reset keys applied fordestruction (reset) processing of the registration key, and further,random number generating keys, mutual authentication keys, etc. Notethat the storage region of the registration key is in a memory regiondetermined by an address determined beforehand. The registration key andreset key will be described later in detail.

Identification information: For the identification information, thesecurity chip ID serving as the identifier of the security chip isstored. Also, a service provider ID serving as an identifier of aservice provider (SP) from which continuous service is to be received, auser ID provided to a user using the user device, an application ID foridentifying an application corresponding to a service provided by theservice provider, and so forth, can also be stored.

Other: The user device also stores random number generating seedinformation, i.e., information for generating random numbers used forauthentication processing, enciphering processing, etc., following ANSIX9.17, and usage information relating to services to which various usagerestrictions have been applied, for example, information such asinformation regarding the number of times of using contents updated atthe time of using contents with contents usage number-of-timerestrictions, information such as payment information or the like, andfurther, hash values calculated based on the information.

Note that the configuration example shown in FIG. 10 is only an example,and that various types of information other than these relating to theuser device receiving services can be sorted as necessary.

Also, note that the security chip or security module of the serviceprovider side at the service providing side for example, can also berealized with a configuration similar to the security chip configurationat the user device shown in FIG. 9, so as to function as the variousexecuting means for the later-described group attribute certificateverification processing and generating processing, and executionattribute certificate verification processing and generating processing.For example, the same configuration as the security chip shown in FIG. 9can be applied as means for executing verification processing of a groupattribute certificate or execution attribute certificate received viathe network interface which is a data transmission/reception unit, ormeans for executing generating processing of a group attributecertificate or execution attribute certificate.

[(3) Group Attribute Certificate Issuing and Usage Processing]

Next, the group attribute certificate issuing processing and usageprocessing for setting multiple users or devices as a group, such as auser belonging to various sets such as the same organization such as aschool or company, or one family, or the like, or such as devicesmanufactured by the same manufacturer, users and devices and the likereceiving the services of the same service provider, and so forth, asone group, and issuing a group attribute certificate to each of theusers or devices belonging to the group, will be described.

A group attribute certificate is a certificate whereby the fact that auser or device (user device) attempting to receive a service belongs toa certain group can be confirmed, and is presented to a serviceproviding entity, a service provider for example, at the time ofreceiving the service. The service provider executes verificationprocessing of the group attribute certificate presented thereto, andprovides the service under the condition that confirmation has been madethat the user or user device belongs to the certain group.

A group attribute certificate is a certificate which has, as storedinformation, group identification information set corresponding to thegroup made up of a set of certain devices or certain users, and carriesthe electronic signature of the issuer.

FIG. 11 schematically illustrates the flow of issuing application,issuing processing, and usage processing, of the group attributecertificate. A user device 311 which desires to receive servicesprovided by a service provider 314 which provides services under thecondition that confirmation of proof of belonging to a group based onthe group attribute certificate is made, i.e., an end entity (EE) oruser identification device (UID) having a security chip, first makes anissue request to the issuing entity for the group attribute certificate.For example, an application for issuing a group attribute certificate ismade to a attribute registration authority (ARA) 312.

The attribute registration authority (ARA) 312 makes reference to theissuing policy table 313 based on the issuing application, and in theevent that the policies are satisfied, commissions the attributeauthority (AA) to issue an attribute certificate, and transmits thegroup attribute certificate 316 which the attribute authority (AA) hasissued, to the user device 311.

The group attribute certificate 316 stores a group ID serving as a groupidentifier, in the attribute information field (see FIG. 5). The userdevice 311 presents the group attribute certificate 316 to the serviceprovider 314 at the time of receiving some sort of service provided bythe service provider 314, such as contents distribution, paymentprocessing, etc., for example. The service provider 314 determineswhether or not the user device 311 requesting the service to be providedhas privileges for receiving the service, by verification processing ofthe group attribute certificate and by making reference to the groupinformation database 315, and in the event that determination is madethat the user device 311 has the privileges, providing of the servicesthereto is executed.

Now, with regard to the group attribute certificate issuing and usageprocessing, the three items of

(3-1) Preparation processing before issuing group attribute certificate

(3-2) Group attribute certificate issuing processing

(3-3) Group attribute certificate usage processing will be described inorder.

(3-1) Preparation Processing Before Issuing Group Attribute Certificate

First, the preparation processing before issuing the group attributecertificate will be described. As described above, with the normalstyle, the group attribute certificate is basically issued by theattribute authority (AA), the attribute registration authority (ARA)receives an issuing request from the attribute certificate issuingrequesting entity, policy screening and the like is executed,determination is made that issuing is permissible, following which theattribute certificate issuing request is transferred to the attributeauthority (AA), and an attribute certificate issued by the attributeauthority (AA) is transmitted to the issue requesting entity via theattribute registration authority (ARA). However, as described below,issuing can be made at the service provider (SP) and user device, underrespective policies thereof.

The group attribute certificate according to the present invention isissued to members (devices or users) making up a group, upon havingdetermined some sort of an identifiable group, such as a family, school,company, devices of a certain manufacturer, or the like, while a serviceprovider providing services determines whether or not a user or devicerequesting services belongs to a certain group, based on the groupattribute certificate. Accordingly, in the event that there is the needfor the group attribute certificate issuing processing executing entityand the entity for executing privilege confirmation (verificationprocessing) based on the group attribute certificate and providingservice to have a common understanding of the group definedcorresponding to the group attribute certificate, processing for sharinginformation relating to the group defined corresponding to the groupattribute certificate, i.e., group information, between the groupattribute certificate issuing entity and service providing entity, asthe preparation processing before issuing the group attributecertificate, is required.

The following is a description with reference to FIG. 12 regarding groupinformation sharing processing in a case wherein the group attributecertificate issuing entity is an attribute authority (AA) or attributeregistration authority (ARA), and the service providing entity is aservice provider (SP).

Note that in the following description, the attribute authority (AA) andthe attribute registration authority (ARA) are in a trust relation, anddescription will be made with an example of a configuration wherein theattribute registration authority (ARA) performs screening for issuingthe group attribute certificate, and the attribute authority (AA)performs group attribute certificate issuing processing based on thescreening results performed by the attribute registration authority(ARA). Accordingly, the group information sharing entities are theservice provider (SP) and attribute registration authority (ARA), thesetwo.

The group information sharing processing between the service provider(SP) and attribute registration authority (ARA) will be describedfollowing the processing sequence diagram shown in FIG. 12.

First, in step S101, mutual authentication processing is executedbetween the service provider (SP), and the attribute registrationauthority (ARA) which executes issuing screen for the group attributecertificate. Note that hereafter, the attribute registration authority(ARA) which executes issuing screen for the group attribute certificatewill be referred to as group attribute certificate registrationauthority (ARA).

The mutual authentication performed between the service provider (SP)and the group attribute certificate registration authority (ARA) isprocessing executed in order to confirm between the two entitiesexecuting data transmission/reception whether or not the other party isthe proper data communication party. Data transfer is performed underthe conditions that authentication is established. Also, a session keyis preferably generated at the time of mutual authentication processing,for a configuration wherein data transfer is made under enciphermentprocessing based on the session key as a shared key. Either public keyencipherment or shared key encipherment may be used for the mutualauthentication method.

Here, the handshake protocol (TLS 1.0), a mutual authentication methodwhich is a type of public key encipherment method, will be describedwith reference to the sequence diagram shown in FIG. 13.

In FIG. 13, an entity A (client) and entity B (server) are the twoentities for executing communication, and here corresponding to heservice provider (SP) or group attribute certificate registrationauthority (ARA). First, (1) the entity B transmits a negotiation startrequest for determining the encipherment specifications to the entity Aas a hello request. (2) The entity A, upon receiving the hello request,transmits the encipherment algorithm, session ID, and protocol versioncandidates, to the entity B side, as a client hello.

(3) The entity B side transmits the enciphered algorithm, session ID,and protocol version, regarding which usage has been determined, to theentity A as a service hello. (4) the entity B transmits a set of publickey certificates (X. 509v3) up to its own root CA, to the entity A(server certificate). In the event of not tracing the certificate chainin order to perform verification up to the highest-order public keycertificate, transmitting the set of public key certificates (X. 509v3)up to the root CA is not absolutely necessary. (5) the entity Btransmits an RSA public key or Diffie & Hellman public key informationto the entity A (server key exchange). This is public key information tobe temporarily applied in the event that the certificate cannot be used.

(6) Next, the entity B side requests a certificate of the entity A as acertificate request to the entity A, and (7) notifies the end ofnegotiation processing by the entity B (server hello end).

(8) the entity A which has received the server hello end transmits theset of public key certificates (X. 509v3) up to its own root CA (clientcertificate) to the entity B. In the event that chain verification ofthe public key certificate is not performed, transmitting the set ofpublic key certificates is not absolutely necessary. (9) The entity Aenciphers a 48-byte random number with the public key of the entity Bz,and transmits this to the entity B. The entity B and the entity Agenerate a master secret including data and the like for generating amessage authentication code (MAC) for transmission/reception dataverification processing, based on this value.

(10) the entity A enciphers a digest of the message so forth using thesecret key of the client, to confirm the correctness of the clientcertificate, transmits this to the entity B (client certificate verify),(11) notifies start of usage of the encipherment algorithm and keydetermined earlier (change cipher spec), and (12) notifies the end ofauthentication. On the other hand, (13) the entity B side also notifiesthe entity A of start of usage of the encipherment algorithm and keydetermined earlier (change cipher spec), and (14) notifies the end ofauthentication.

Data transfer between entity A and entity B is then executed followingthe encipherment algorithm determined in the above processing.

Verification of data tampering is performed by adding a messageauthentication code (MAC), calculated from the master secret generatedupon agreement between the entity A and entity B in the aboveauthentication processing, to the transmitted data of each entity,thereby performing message tampering verification.

FIG. 14 illustrates the generating configuration of a messageauthentication code (MAC). The data transmitting side adds a MAC secretgenerated based on a master secret generated in the authenticationprocessing, to transmitted data, calculates a hash value from the entiredata, and further calculates a hash based on the MAC secret, padding,and hash value, thereby generating a message authentication code (MAC).The generated MAC is attached to the transmitted data, and in the eventthat the received MAC matches the MAC generated based on the receptiondata at the reception side, the data is determined to be not tamperedwith, and in the event that these do not match, the data is determinedto have been tampered with.

In step S101 shown in FIG. 12, mutual authentication processing,following the above-described sequence for example, is performed betweenthe service provider (SP) and the attribute registration authority (ARA)which has executed the group attribute certificate issuing screening,and upon confirmation being made that both are the correct communicationparties, in step S102 group information sharing processing is executedbetween the service provider (SP) and the attribute registrationauthority (ARA).

Specifically, group information sharing is performed as processingwherein the issuing policy table managed by the group attributecertificate issuing entity (e.g., the attribute registration authority(ARA)), and the group information database of the service providingentity (e.g., the service provider (SP)) based on verification andverification of the group attribute certificate, are set so as to holdmatching information.

As described above, the group attribute certificate issuing entity(e.g., the attribute registration authority (ARA)) has an issuing policytable, and the service providing entity (e.g., the service provider(SP)) based on verification and verification of the group attributecertificate has a group information database. FIG. 15 illustrates aconfiguration example of the information.

The (A) issuance policy table is held and managed by the attributeregistration authority (ARA), and is referred to for group attributecertificate issuing processing and the like. On the other hand, the (B)group information database (DB) is held and managed by the serviceprovider (SP), and reference is made thereto at the time of verifyingthe group attribute certificate when providing services.

It is necessary that the (A) issuance policy table held and managed bythe attribute registration authority (ARA), and the (B) groupinformation database (DB) held and managed by the service provider (SP)agree. In the example shown in FIG. 15, the entry 341 of the (A)issuance policy table agrees with the entry 351 of the (B) groupinformation database (DB), and the entry 342 of the (A) issuance policytable agrees with the entry 352 of the (B) group information database(DB). This agreement maintaining processing between the (A) issuancepolicy table held and managed by the attribute registration authority(ARA), and the (B) group information database (DB) held and managed bythe service provider (SP) is the group information sharing processingstep S102 in the sequence diagram of FIG. 12.

Note that there are the following two examples for arrangements of groupinformation sharing processing.

Policy acceptance type: A service providing entity (e.g., the serviceprovider (SP)) based on verification and verification of the groupattribute certificate studies issuing policies of various groupattribute certificate issuing entities (e.g., attribute registrationauthority (ARA)), selects a group ARA suitable for its own services, andthe service provider (SP) obtains the group information which the groupARA selected here manages.

Issuance commissioning type: An issuing policy set by a serviceproviding entity (e.g., the service provider (SP)) based on verificationand verification of the group attribute certificate is presented to agroup attribute certificate issuing entity (e.g., group attributecertificate registration authority (ARA)) which does not have its ownattribute certificate issuing policies but simply is commissioned toissue group attribute certificates, and the group attribute certificateregistration authority (ARA) performs group attribute certificateissuing processing following the policy presented thereto.

Various arrangements can be made for specific group information sharingprocessing arrangements, such as an arrangement wherein informationrelating to a group attribute certificate, such as group ID, issuer,group information, issuing policy, etc., are set by the group attributecertificate issuing entity (e.g., group attribute certificateregistration authority (ARA)), presented to a service providing entity(e.g., the service provider (SP)) based on verification and verificationof the group attribute certificate, and both entities agree thereupon;an arrangement wherein the service provider sets such information andpresents the information to the group ARA, with both entities agreeingthereupon; an arrangement wherein the information of each is set byeach, and the overall information is mutually agreed on; an arrangementwherein the service provider unilaterally trusts the group attributecertificate registration authority (ARA); and so forth.

Note that in the case of the issuance commissioning arrangement, in theevent of a new service provider (SP) starting a new service using groupattribute certificates, the attribute registration authority (ARA)performs registration screening of the service provider (SP) itself,following which the above-described group information sharing processingis performed.

Upon the group information sharing processing of step S102 ending, instep S103 the service provider (SP) executes data updating processingbased on the agreed information, with regard to the group informationdatabase managed by itself. As shown in FIG. 15, the group informationdatabase stores the data of issuer, group identification information(group ID), and group information, and data registration and updatingregarding this information is executed. On the other hand, in step S104,the attribute registration authority (ARA) executes data updatingprocessing based on the agreed information, with regard to the issuingpolicy table managed by itself. As shown in FIG. 15, the issuing policytable stores the data of the group ID, group information, and issuingpolicy, and data registration and updating regarding this information isperformed.

Note that the above-described processing is processing which isnecessary in the event that the service provider (SP) and the attributeregistration authority (ARA) are configured as independent entities, andin the event that the service provider (SP) also serves as the attributeregistration authority (ARA), the service provider (SP) itself holds andmanages both the group information database and the issuing policytable, so the group information sharing processing between the serviceprovider (SP) and the attribute registration authority (ARA) asdescribed above can be omitted.

Also, note that the above-described example is a case wherein the groupattribute certificate issuing entity is an attribute registrationauthority (ARA) and the service providing entity based on verificationand verification of the group attribute certificate is a serviceprovider (SP), but the above-described processing is executed accordingto combinations of the various entities.

(3-2) Group Attribute Certificate Issuing Processing

Next, group attribute certificate issuing processing will be describing.The group attribute certificate issuing processing is executed by theattribute authority (AA), as a rule. However, service providers and userdevice can also issue based on own issuing policies. In the following, agroup attribute certificate issuing processing sequence by the attributeauthority (AA) will be described.

With a normal attribute certificate issuing sequence, a processingarrangement wherein the attribute registration authority (ARA) receivesan issuing request from an attribute certificate issue requestingentity, executes policy screening or the like, and following determiningthat issuing is permissible, transfers an attribute certificate issuerequest to the attribute authority (AA), and the attribute certificatewhich the attribute authority (AA) issues is transferred to the issuerequesting entity via the attribute registration authority (ARA).

The processing in a case wherein the security chip (SC) of the endentity (EE), which is a user device, is the group attribute certificateissue requesting entity, will be described with reference to FIG. 16.Note that in FIG. 16,

UID: user identification device (user device) control unit,

USC: user security chip configured within the UID,

EE: end entity (user device) control unit,

SC: security chip configured within the EE,

Group ARA: group attribute certificate registration authority controlunit, and

Group AA: group attribute authority control unit.

First, in step S111, the user inputs an issue request command for agroup attribute certificate (Gp. AC) via the input interface of the endentity (EE). At this time, the user inputs attribute values necessaryfor issuing the group attribute certificate. The attribute values arethe group ID, information proving belonging to the group, or the like.

Upon the end entity (EE) receiving input of the group attributecertificate (Gp. AC) issuing request for the user, in step S112 the endentity (EE) makes a connection request to the group ARA, and in stepS113 outputs a mutual authentication start request to the security chip(SC) within the end entity (EE).

In step S114, mutual authentication is carried out between the securitychip and the group ARA. This is executed as mutual authenticationprocessing of the public key method described earlier with reference toFIG. 13, for example. In step S115, a mutual authentication completionnotification is output from the security chip to the end entity,including results information of establishment or non-establishment ofmutual authentication. In the event that mutual authentication is notestablished, continuation of processing is cancelled. In the event thatmutual authentication is established, in step S116 the end entity (EE)transmits a group attribute certificate (Gp. AC) issuing request to thegroup ARA. This group attribute certificate (Gp. AC) issuing requestincludes end entity information, and attribute information (e.g., groupID, group information).

In step S117, the group ARA which has received the group attributecertificate (Gp. AC) issuing request from the end entity (EE) makesreference to the issuing group policy table, determines whether or notissuing of a group attribute certificate compliant with the policy canbe made, and in the event that this can be made, the flow proceeds tostep S118, while in the event that this cannot be made, a issuenot-permitted message is notified to the end entity.

In step S118, the group ARA transmits the group attribute certificate(Gp. AC) issuing request having the attribute values (group ID) to thegroup AA, and in step S119, the group AA stores the group ID asattribute information, generates a group attribute certificate (see FIG.5) with an electronic signature attached, and transmits this to thegroup ARA.

In step S120, the group ARA transmits the issued group attributecertificate (Gp. AC) to the end entity (EE). The end entity (EE) storesthe received group attribute certificate (Gp. AC) in the memory thereof.At this time, verification of the electronic signature of the receivedgroup attribute certificate (Gp. AC) is performed, and followingconfirmation that there is no tampering, this is stored in memory.

The electronic signature generating executed by the group AA at the timeof generating the group attribute certificate, and the electronicsignature verification processing executed by the end entity at the timeof storing the group attribute certificate, will be described withreference to FIG. 17 and FIG. 18.

A signature is attached to enable verification of data tampering, andthe aforementioned MAC value may be used, and an electronic signatureusing the public key encipherment method may also be used.

First, a method for generating an electronic signature using the publickey encipherment method will be described with reference to FIG. 17. Theprocessing shown in FIG. 17 is electronic signature data generatingprocessing using EC-DSA ((Elliptic Curve Digital Signature Algorithm),IEEE P1363/D3). The example described here uses the Elliptic CurveCryptosystem (hereafter, ECC) as public key encipherment. Note that withthe data processing device according to the present invention, similarpublic key encipherment such as RSA encipherment ((Rivest, Shamir,Adleman), etc. (ANSI X9.31)) may also be used besides the Elliptic CurveCryptosystem.

The steps in FIG. 17 will be described. In step S1, p as prime, a and bas elliptic curve coefficients (elliptic curve: y²=x³+ax+b, 4a³+27b²≠0(mod p)), G as the base point on the elliptic curve, r as the order ofG, and Ks as the secret key (0<Ks<r). In step S2, the hash value of themessage M is calculated, with f=Hash(M).

Now, the method for obtaining a hash value using a hash function will bedescribed. A hash function is a function wherein a message is taken asinput, this is compressed into data of a predetermined bit length, andoutput as a hash value. The hash function is difficult to predict frominput of the hash value (output), and changing 1 bit of the data inputto the hash function changes a great number of bits in the hash value,and further, finding different input data with the same hash value isdifficult. There are cases wherein MD4, MD5, SHA-1, or the like are usedfor hash functions, and cases wherein DES-CBS is used. In this case, theMAC which is the final output (check value: equivalent to ICV) is thehash value.

Next, in step S3, a random number u (0<u<r) is generated, and in step S4coordinates V (Xv, Yv) wherein the base point is multiplied by u arecalculated. Note that addition and doubling on the elliptic curve aredefined as follows.

-   -   With P=(Xa, Ya), Q=(Xb, Yb), R=(Xc, Yc)=P+Q, at the time of P≠Q        (addition),        Xc=λ ² −Xa−Xb        Yc=λ×(Xa−Xc)−Ya        λ=(Yb−Ya)/(Xb−Xa),    -   and at the time of P=Q (doubling),        Xc=λ ²−2Xa        Yc=λ×(Xa−Xc)−Ya        λ=((3Xa)² +a)/(2Ya)

These are used to calculate u times the point G (though slow, thecomputation method which is the easiest to understand is performed asfollows. G, 2×G, 4×G, and so on, is calculated, u is converted to binaryand 2^(i)×G (a value wherein G is doubled i times (i being the bitposition of u counted from LSB)) is added to the ones).

In step S5 c=Xv mod r is calculated, in step S6 determination is maderegarding whether this value is 0, and if not 0, in step S7d=[(f+cKs)/u] mod r is calculated, in step S8 determination is maderegarding whether d is 0, and if not 0, in step S9 c and d are output aselectronic signature data. Assuming that r has a bit length of 160, theelectronic signature data will be 320 bits long.

In the event that c is 0 in step S6, the flow returns to step S3 and anew random number is generated again. In the same way, in the event thatd is 0 in step S8, the flow returns to step S3 and the random number isgenerated again.

Next, the verification method for the electronic signature using thepublic key encipherment method will be described with reference to FIG.18. In step S11, M is the message, p prime, a and b as elliptic curvecoefficients (elliptic curve: y²=x³+ax+b, 4a³+27b≠0 (mod p)), G as thebase point on the elliptic curve, r as the order of G, and G and Ks×G asthe public key (0<Ks<r). In step S12, whether or not the electronicsignature data c and d satisfy 0<c<r, 0<d<r is verified. In the eventthat this is satisfied, the hash value of the message M is calculated instep S13, as f=Hash(M). Next, in step S14, h=1/d mod r is calculated,and in step S15, h1=fh mod r, h2=ch mod r are calculated.

In step S16, the already-calculated h1 and h2 are used to calculatepoint P=(Xp, Yp)=h1×G+h2·Ks×G. The electronic signature verifier knowsthe base point G and Ks×G, so calculation of multiplication by scalarsof the point on the elliptical curve can be calculated in the same wayas with step S4 in FIG. 17. In step S17, determination is made regardingwhether or not the point P is an infinite apoapse, and if not aninfinite apoapse the flow proceeds to step S18 (in reality,determination of infinite apoapse can be made in step S16. that is,adding P=(X, Y), Q=(X, −Y) shows that λ cannot be calculated, therebyrevealing that P+Q is an infinite apoapse. In step S18, Xp mod r iscalculated, and compared with the electronic signature data c. Finally,in the event that this value matches, the flow proceeds to step S19, anddetermination is made that the electronic signature is correct.

In the event that determination is made that the electronic signature iscorrect, this tells that the data has not been tampered with, and thatthe holder of the secret key corresponding to the public key hasgenerated the electronic signature.

In step S12, in the event that either electronic signature data c or ddo not satisfy 0<c<r, 0<d<r, the flow proceeds to step S20. Also, in theevent that the point P is an infinite apoapse in step S17 as well, theflow proceeds to step S20. Moreover, in the event that the value of Xpmod r does not match the electronic signature data c in step S18 aswell, the flow proceeds to step S20.

In the event that determination is made that the electronic signature isnot correct in step S20, this tells that either the data has beentampered with, or that the holder of the secret key corresponding to thepublic key has not generated the electronic signature. As mentionedabove, while removing the signature and hash will enable tampering,detection thereof means the effects are essentially the same as beingtamper-proof.

Next, the procedures for issuing the group attribute certificatecorresponding to the user security chip (USC) within the useridentification device (UID) will be described with reference to FIG. 19.As described above, the UID is configured so as to be capable ofexternal communication via the end entity (EE), so attribute certificateobtaining processing is also executed via the end entity (EE).

The processing in steps S131 through S135 is the same processing as thatin steps S111 through 115 described with reference to FIG. 16, andaccordingly description thereof will be omitted.

Upon mutual authentication between the security chip (SC) within the endentity and the group ARA being established in step S134, in step S137mutual authentication between the user security chip (USC) within theuser identification device (UID) and the security chip (SC) within theend entity is executed. This authentication processing is carried outvia the connected device interface 231 (see FIG. 9) of the end entity(EE) and the user identification device (UID). This authenticationprocessing can be executed as authentication processing based on thepublic key method described earlier with reference to FIG. 13, asprocessing centered on the encipherment processing unit (see FIG. 9) ofthe security chip and security module. In step S138, authenticationcompletion notification including authentication established informationis made to the end entity (EE), and the flow proceeds to the next stepunder the condition that authentication has been established.

In step S139, a user security chip (USC) mutual authentication startrequest is output from the end entity (EE), and in step S140, mutualauthentication is executed between the USC and the group ARA. In stepS141, an authentication completed notification including authenticationestablished information is notified from the USC to the end entity (EE),and under the condition that authentication has been established, theend entity (EE) transmits a group attribute certificate (Gp. AC) issuerequest to the group ARA in step S142. The group attribute certificate(Gp. AC) issue request includes the end entity information, andattribute values (e.g., group ID, group information).

Upon receiving the group attribute certificate (Gp. AC) issue requestfrom the end entity (EE), the group ARA makes reference to the issuingpolicy table in step S143, determines whether or not a group attributecertificate can be issued in compliance with the policy, and if this canbe issued, the flow proceeds to step S144, and if this cannot be issued,the end entity is notified of a issuing no-permissible message.

In step S144, the group ARA transmits a group attribute certificate (Gp.AC) issuing request accompanied by attribute values (group ID) to thegroup AA, and in step S145, the group AA stores the group ID asattribute information, generates a group attribute certificate (see FIG.5) with an electronic signature attached, and transmits this to thegroup ARA.

In step S146, the group ARA transmits the issued group attributecertificate (Gp. AC) to the UID via the end entity (EE). The UID storesthe received group attribute certificate (Gp. AC) in memory. At thistime, verification of the electronic signature of the group attributecertificate (Gp. AC) is performed, and after confirmation is made thatthere is no tampering, storage in memory is performed.

As described above, in order for a user identification device (UID)which does not have direct communication functions with the group ARA toobtain a group attribute certificate corresponding to the user securitychip (USC), there is the need to go through the end entity (EE). At thistime, establishment of all of:

(1) Mutual authentication between the SC of the EE and the group ARA,

(2) Mutual authentication between the SC of the EE and the USC of theUID, and

(3) Mutual authentication between the USC of the UID and the group ARA,

for example, in order for mutual authentication to be carried outbetween the user security chip (USC) and the group ARA. Or as a simplerconfiguration, a processing configuration may be made wherein the EEbasically accepts (deems authenticated) the UID upon connection to theEE, and in this case, the mutual authentication (2) above can beomitted. Further, authentication configurations under differentcombinations of the above three types can be realized.

(3-3) Group Attribute Certificate Usage Processing

The processing for using a group attribute certificate stored in asecurity chip (SC) within a user device, or a user security chip (USC),will be described. Description here will not make mention of specificservice forms, and will deal with service usage privilege authenticationprocessing based on the group attribute certificate, up to starting ofthe services. Specific service arrangements will be described laterunder a different item.

The processing up to the starting of services, including service usageprivilege confirmation using the group attribute certificate issued tothe security chip (SC) within an end entity (EE) service as a userdevice, will be described with FIG. 20 on. Note that in FIG. 20,

UID: user identification device (user device) control unit,

USC: user security chip configured within the UID,

EE: end entity (user device) control unit,

SC: security chip configured within the EE,

SP: service provider control unit, and

SM: security module within SP.

Also note that the security chip (SC) of the user device (EE), the usersecurity chip (USC) of the user identification device (UID), and thesecurity module of the service provider (SP), have the sameconfiguration as the security chip described earlier in FIG. 9, forexample.

First, in step S151, a user inputs a group attribute certificate (Gp.AC) usage request command via the input interface of the entity (EE). Atthis time, the user specifies he group ID set in the group attributecertificate to be used. However, in the event that a single group ID canbe determined by specifying a certain service, an arrangement may bemade wherein only the service is specified.

Upon the end entity (EE) receiving the group attribute certificate (Gp.AC) usage request input from the user, the end entity (EE) makes aconnection request to the service provider (SP) in step S152, and on theother hand, in step S153 outputs a mutual authentication start requestto the security chip (SC) within the end entity (EE).

In step S154, mutual authentication between the security chip and thesecurity module (SM) of the service provider (SP) is carried out. Thisis processing centered on the encipherment processing unit 205 shown inFIG. 9 for example, configured within the security chip of the securitymodule (SM) of the service provider (SP), and is executed as public keymutual authentication processing described earlier with reference toFIG. 13, for example.

In step S155, a mutual authentication completion notification includingmutual authentication established/not-established results information,is output from the security chip to the end entity. In the event thatmutual authentication is not established, continuing processing iscancelled. In the event that mutual authentication is established, instep S156 the end entity (EE) transmits the group attribute certificate(Gp. AC) stored in its own memory to the security module (SM) of theservice provider (SP). Or, a configuration may be made whereintransmission of the group attribute certificate (Gp. AC) is made inresponse to a transmission request from the service provider (SP). Also,there are cases wherein the end entity (EE) makes a usage request forthe group attribute certificate (Gp. AC) along with transmission of thegroup attribute certificate (Gp. AC). This group attribute certificate(Gp. AC) stores the group identification information (group ID) as anattribute value.

The service provider receives the group attribute certificate (Gp. AC)from the end entity (EE) using a network interface having the sameconfiguration as that of the user device shown in FIG. 9 for example, asa reception unit, and transfers this to the security module (SM). Thesecurity module (SM) executes group attribute certificate verificationprocessing in step S157. As described earlier, the security module hasthe same configuration as the security chip of the user device shown inFIG. 9, so the security module functions as the group attributecertificate verification processing unit.

The details of verification processing of the group attributecertificate will be described with reference to FIG. 21 through FIG. 23.First, the correlation confirmation processing between the attributecertificate (AC) and the public key certificate (PKC) will be describedwith reference to FIG. 21. The flowchart shown in FIG. 21 isconfirmation processing for the public key certificate (PKC) related tothe attribute certificate (AC) performed at the time of verifying theattribute certificate (AC).

Upon the attribute certificate (AC) to be confirmed being set (S21), thepublic key certificate information (holder) field of the AC holder ofthe attribute certificate is extracted (S22), the issuer information ofthe public key certificate (PKC issuer) and public key certificateserial number (PKC serial), which are stored within the extracted keycertificate information (holder) field, are confirmed (S23), the publickey certificate (PKC) is searched based on the issuer information of thepublic key certificate (PKC issuer) and public key certificate serialnumber (PKC serial) (S24), and the public key certificate (PKC)correlated with the attribute certificate (AC) is obtained (S25).

As shown in FIG. 21, the attribute certificate (AC) and the public keycertificate (PKC) are correlated by the issuer information of the publickey certificate (PKC issuer) and public key certificate serial number(PKC serial) stored in the public key certificate information (holder)field of the AC holder of the attribute certificate.

Next, verification processing of an attribute certificate (AC) will bedescried with reference to FIG. 22. First, the attribute certificate(AC) to be verified is set (S51), and the holder of the attributecertificate (AC) and the signer thereof are identified, based on thestored information of the attribute certificate (AC) (S52). Further, thepublic key certificate of the holder of the attribute certificate (AC)is obtained either directly or from a repository (S53), and public keycertificate verification processing is executed (S54).

Verification processing of a public key certificate (PKC) will bedescribed with reference to FIG. 23. Verification of the public keycertificate (PKC) shown in FIG. 23 is a chain processing flow whereinchain information is obtained by tracking the certificate chain fromlower order to higher order, up to the highest-order public keycertificate, and verifying the signature of the public key certificatesup to the highest order (root CA). First, the public key certificate(PKC) to be verified is set (S31), and the signer of the public keycertificate (PKC) is identified, based on the stored information of thepublic key certificate (PKC) (S32). Further, whether or not this is thehighest-order public key certificate of the certificate chain to beverified is determined (S33), and in the event that this is not thehighest-order, the highest-order public key certificate is obtainedeither directly or from a repository or the like (S34). Upon thehighest-order public key certificate having been obtained and set (S35),a verification key (public key) necessary for signature verification isobtained (S36), whether or not the signature to be verified is an ownsignature is determined (S37), and in the event that this is not an ownsignature, an lower-order PKC is set (S39), and signature verificationis executed based on the verification key (public key) obtained from thehigher-order public key certificate (S40). That is to say, in the ownsignature determination in step S37, in the event that the signature isan own signature verification is executed with own public key as averification key (S38), and the flow proceeds to step S41.

In the event that signature verification is successful (Yes in S41),determination is made regarding whether or not verification of theobject PKC has been completed (S42), and in the event that this has beencompleted, PKC verification ends. In the event that this is notcompleted, the flow returns to step S36, and obtaining of a verificationkey (public key) necessary for signature verification and signatureverification of a lower-order public key certificate is repeated. In theevent that signature verification fails (No in S41), the flow proceedsto step S43, and error processing, such as stopping subsequentprocessing for example, is executed.

Returning to step S22, let us continue with description of attributecertificate verification processing. In the event that verification ofthe public key certificate described in FIG. 23 fails (No in S55), theflow proceeds to step S56, and error processing is performed. Forexample, subsequent processing is cancelled. In the event thatverification of the public key certificate is successful (Yes in S55), apublic key certificate corresponding to the signer of the attributecertificate (AC) is obtained either directly or from a repository or thelike (S57), and verification processing of the public key certificatecorresponding to the signer of the attribute certificate (AC) isexecuted (S58).

In the event that verification of the public key certificatecorresponding to the signer of the attribute certificate (AC) fails (Noin S59), the flow proceeds to step S60, and error processing isperformed. For example, subsequent processing is cancelled. In the eventthat verification of the public key certificate is successful (Yes inS59), the public key is extracted from the public key certificatecorresponding to the signer of the attribute certificate (AC) (S61), andsignature verification processing of the attribute certificate (AC) isperformed using the extracted public key (S62). In the event of failingin the signature verification (No in S63), the flow proceeds to stepS64, and error processing is performed, For example, subsequentprocessing is cancelled. In the event of succeeding in the signatureverification (Yes in S63), the attribute certificate verification ends,and the flow proceeds to subsequent processing, i.e., other conditionconfirmation processing to be executed for providing services.

Let us now return to the sequence diagram in FIG. 20 to continuedescription. Upon verification of the group attribute certificate (Gp.AC) in step S157 being executed by the above-described processing, thesecurity module (SM) outputs the verification results to the serviceprovider (SP), and in the event that verification is not successful,error processing is performed and providing of services is cancelledwithout being executed. In this case, processing may be executed whereinthe end entity is notified that verification of the group AC wasunsuccessful.

Upon verification of the group attribute certificate (Gp. AC) succeedingand the authenticity of the group attribute certificate (Gp. AC) beingconfirmed, the flow proceeds to step S161. The processing from step S161on will be described with reference to FIG. 24. In step S161, screeningof the group attribute certificate (Gp. AC) is performed. Screening isexecuted based on the group information database which the serviceprovider holds.

The screening processing of the group attribute certificate (Gp. AC)will be described with reference to FIG. 25. In step S161-1, the serviceprovider (SP) obtains issuer information from the verified groupattribute certificate (Gp. AC). Further, in step S161-2, the attributevalue, i.e., the group identification information (group ID) is obtainedfrom the attribute field.

In step S161-3, the group information data is searched based on the ACissuer and group ID obtained from the group attribute certificate (Gp.AC), and whether or not a registered entry exists is confirmed. In theevent that there is a corresponding registration entry, groupinformation is obtained from the group information database in stepS161-4.

Let us return to the sequence diagram in FIG. 24 to continuedescription. In the event that there is no group information registeredcorresponding to the group attribute certificate (Gp. AC), or in theevent that user does not satisfy the conditions indicated in the groupinformation, screening is unsuccessful (No in S162), and errorprocessing is executed in step S163. For example, a message to theeffect that the screening of the group AC has been unsuccessful and theservice cannot be executed, is notified to the end entity (EE). Also, inthe event that verification and screening of multiple group attributecertificates is necessary for providing services, the conditions aremanaged in a service information database.

The service information database is a database storing informationregarding what group AC is necessary for providing services. However,there is no particular need to hold the aforementioned group informationdatabase and the service information database independent one fromanother, and a database configuration may be made wherein the groupinformation database and the service information database are integratedor linked. That is to say, a configuration may be made wherein dataregarding which group AC is necessary to provide services is obtainedfrom the above group information database or link information of thegroup information database. In the following, description will be madewith the group information database also functioning as a serviceinformation database.

Let us return to the sequence diagram in FIG. 24 to continuedescription. In the event that screening is successful (Yes in S162),whether or not other conditions are necessary for executing service isdetermined. The conditions are conditions which the service provider canoptionally set. Further, in step S165, determination is made regardingwhether or not other group attribute certificates are necessary toprovide services.

This is assuming a case wherein, as shown in FIG. 26, the user or userdevice belongs to multiple different groups as service providingconditions. For example, as shown in FIG. 26(a), a setting can be madewherein service is provided by proving belong to two different groups.

Specifically, the setting is that service is provided upon presentingand verification of two group attribute certificates; a group attributecertificate A (group A) proving that the residence of the user belongsto a certain region, and a group attribute certificate B (group B)indicating that the user device is a device of a certain manufacturer.

Further, as shown in FIG. 26(b), settings can be made wherein service isprovided by proving belonging to three or more different groups.Specifically, the setting is that service is provided upon presentingand verification of three group attribute certificates; a groupattribute certificate A (group A) proving that the residence of the userbelongs to a certain region, a group attribute certificate B (group B)indicating that the user device is a device of a certain manufacturer;and a group attribute certificate C (group C) indicating that the age ofthe user is within a certain range.

In this way, in the event of providing services under the condition thatthe user or the user device belongs to multiple different groups,applying two or more different group attribute certificates issued tothe user or user device, the service provider (SP) requests the endentity (EE) to present another group attribute certificate (Gp. AC) instep S166. In step S167, in response to the request, the group attributecertificate is transmitted to the security module (SM) of the serviceprovider (SP) by the end entity (EE). The security module (SM) executesthe processing from S157 on in FIG. 20 regarding the group attributecertificate newly received from the end entity (EE), i.e., groupattribute certificate verification processing, screening processing, andso forth.

Under the condition that verification and screening of the groupattribute certificates necessary for providing services has beensuccessful, service providing is executed in step S168. These servicesare varied such as distribution of contents provided by a serviceprovider, payment processing, remote controlling of devices which areuser devices (e.g., home appliances), remote maintenance processing,communication services, and so forth. Specific examples of these will bedescribed later on.

Next, the processing up to providing of services, based on a groupattribute certificate issued corresponding to a user security chip (USC)within a user identification device (UID) serving as a user devices willbe described with reference to FIG. 27 and FIG. 28. A useridentification device (UID) is a device which functions as an individualidentification device. Group attribute certificates can be individuallyissued to end entities and user identification devices. Basically, agroup attribute certificate issued to a user identification device isissued as a certificate enabling confirmation of whether or not the userhimself/herself is member of a certain group. The UID is of aconfiguration wherein external communication can be made via the endentity (EE), so usage processing of the attribute certificates is alsoperformed via the end entity (EE).

As with the processing in steps S151 through S155 in FIG. 20, the stepS171 through S175 in FIG. 27 are processing centered on mutualauthentication between the security chip (SC) within the end entity (EE)and the security module (SM) of the service provider (SP).

In the event that mutual authentication is established between thesecurity chip (SC) within the end entity and the security module (SM) ofthe service provider (SP) in step S174, mutual authentication isperformed between the user security chip (USC) within the useridentification device (UID) and the security module chip (SC) within theend entity in step S177. This authentication processing is carried outvia the connected device interface 231 (see FIG. 9) of the end entity(EE) and the user identification device (UID). This authenticationprocessing can be executed as authentication processing based on thepublic key method described earlier with reference to FIG. 13, asprocessing centered on the encipherment processing unit (see FIG. 9) ofthe security chip and security module. In step S178, authenticationcompletion notification including authentication established informationis made to the end entity (EE), and the flow proceeds to the next stepunder the condition that authentication has been established.

In step S179, a mutual authentication start request is output to theuser security chip (USC) from the end entity (EE), and in step S180,mutual authentication is executed between the USC and the securitymodule (SM) of the service provider (SP). In step S181, anauthentication completed notification including authenticationestablished information is notified from the USC to the end entity (EE),and under the condition that authentication has been established, theuser identification device (UID) transmits a group attribute certificate(Gp. AC) to the security module (SM) of the service provider (SP) instep S182. The group attribute certificate (Gp. AC) is a group attributecertificate (Gp. AC) issued to the user security chip (USC) of the useridentification device (UID).

Upon receiving the group attribute certificate (Gp. AC) from the usersecurity chip (USC), the security module (SM) of the service provider(SP) executes verification processing of the received group attributecertificate in step S183. This verification processing is the same asthat described with reference to FIG. 21 through FIG. 23. Now, theprocessing of steps S184 through S198 (FIG. 28) is basically the same asthe processing regarding the group attribute certificate correspondingto the security chip (SC) of the end entity described with reference toFIG. 20 and FIG. 24, and accordingly, description thereof will beomitted. However, in step S197 shown in FIG. 28, transmission of a newgroup attribute certificate is performed by the user identificationdevice (UID).

As described above, in the event for a user identification device (UID)which does not have direct communication functions with the serviceprovider (SC) to obtain a group attribute certificate corresponding tothe user security chip (USC), there is the need to go through the endentity (EE). At this time, establishment of all of:

(1) Mutual authentication between the SC of the EE and the serviceprovider (SP),

(2) Mutual authentication between the SC of the EE and the USC of theUID, and

(3) Mutual authentication between the USC of the UID and the serviceprovider (SP),

for example, is performed in order for mutual authentication to becarried out between the user security chip (USC) and the serviceprovider (SP). Or as a simpler configuration, a processing configurationmay be made wherein the EE basically accepts (deems authenticated) theUID upon connection to the EE, and in this case, the mutualauthentication (2) above can be omitted. Further, authenticationconfigurations under different combinations of the above three types canbe realized.

Note that while in FIG. 20 and FIG. 24, processing using a groupattribute certificate corresponding to the security chip (SC) of the endentity (EE) has been described, and in FIG. 27 and FIG. 28, processingusing the group attribute certificate issued to the user security chip(USC) of the user identification device (UID) has been described, but aconfiguration may be made wherein service is provided based onverification and screening of multiple group attribute certificates,namely, a group attribute certificate corresponding to the security chip(SC) of the end entity (EE) and a group attribute certificate issued tothe user security chip (USC) of the user identification device (UID),such as described with reference to FIG. 26 earlier. In this case, theprocessing shown in FIG. 27 and FIG. 28, and the processing shown inFIG. 20 and FIG. 24 is combined and executed.

For example, a configuration can be made wherein the service providerperforms screening regarding whether or not an end entity (devices)serving as a user device is the object of service permission based onfirst group identification information obtained from a first groupattribute certificate based on group definition with the end entity as amember, and performs screening regarding whether or not an user sentfrom the user identification device is the object of service permissionbased on second group identification information obtained from a secondgroup attribute certificate based on group definition with the user as amember, and performs service-permissible determination processing underthe condition that all group identification information has beendetermined to be the object of permitting service.

[(4) Issuing and Usage Processing of Group Attribute CertificatesBetween User Devices]

In the above description, a group attribute certificate has beendescribed as being primarily applied as a certificate for confirmingusage privileges for services to be provided from a service provider toa user device. While the group attribute certificate issuing entity isbasically the group attribute authority (group AA), an arrangement maybe made wherein the service provider (SP) executes the functions of thegroup attribute authority (group AA) and group ARA, to issue groupattribute certificates under the own policies of the service provider(SP). Further, an arrangement may be made wherein a user device itselfexecutes the functions of the group attribute authority (group AA) andgroup ARA, to issue group attribute certificates under the own policiesof the user device. The following is a description of a configurationwherein a user device issues group attribute certificates and executesaccess restrictions to the user device using the group attributecertificates.

As for a specific usage arrangement, let us consider an access privilegemanagement arrangement wherein, in the event that a user device (endentity) which is a communication processing device having communicationfunctions for example, wants to permit access from only certain members,the user device issues group attribute certificates in which the certainmembers are set as a group, and other user devices requesting access arerequired to present the issued group attribute certificate, thepresented group attribute certificate is verified, and access ispermitted.

While this service providing arrangement, i.e., an access permissionservice providing arrangement can be realized with configurationswherein a service provider (SP) issues group attribute certificates,access management can be realized on an individual level by the userdevice setting certain friends, members of a family, same company,school, etc., as a group, and generating and issuing group attributecertificates storing as group identification information correspondingto the set group.

First, with reference to FIG. 29, description will be made with regardto a case wherein group attribute certificates are issued and storedamong user devices.

Description will be made with regard to a case wherein the security chip(SC) of the end entity (EE) serving as the communication processingdevice which is the user device, is the issuing entity of the groupattribute certificate, with reference to FIG. 29. Note that in FIG. 29,

UID: access-requesting user identification device (user device) controlunit,

USC: access-requesting user security chip configured within the UID,

Access-requesting EE: access-requesting end entity (user device) controlunit,

SC1: security chip configured within the access-requesting EE,

Access-requested EE: access-requested end entity (user device) controlunit, and

SC2: security chip configured within the access-requested EE.

Here, the accessing EE and the accessed EE are each different usercommunication processing devices. Also, the security chips (SC1 andSC2), and user security chip (USC) have the same configuration as thesecurity chip described earlier with FIG. 9, executing access privilegedetermining processing and the like by verification of group attributecertificate at the security chips.

That is to say, the access requested device which has received the groupattribute certificate sent from the access requesting device to theaccess requested device, with a reception unit such as a networkinterface of the like, hands the received group attribute certificate tothe security chip serving as the access privilege determining processingunit, and access privilege determining processing is carried out basedon the received group attribute certificate within the security chip.

Note that the processing sequence diagrams of FIG. 29 and on describethe processing procedures from the stage of group attribute certificateissuing processing wherein access privilege is proved. That is top say,first, the security chip of a communication processing device executesgroup attribute certificate generating processing, and performs issuingprocessing of the group attribute certificate proving the privilege.Subsequently, in this sequence, the issued group attribute certificateis exchanged between communication processing devices, therebyconfirming access privileges. Accordingly, the security chip of thecommunication processing device functions as the generating means andverifying means of group attribute certificates.

The processing procedures will be described following the sequencediagram in FIG. 29. First, in step S201, the access requesting userinputs a new issuing command for a group attribute certificate (Gp. AC)via the input interface of the end entity (accessing EE).

Upon the end entity (accessing EE) receiving input of the groupattribute certificate (Gp. AC) issue request from the user, in stepS202, the end entity (accessing EE) makes a connection request to theaccess requested end entity (accessed EE), and on the other hand, instep S203, outputs a mutual authentication start request to the securitychip (SC) within the accessing end entity (accessing EE).

In step S204, mutual authentication is performed between the securitychip (SC1) of the access requesting user device and the security chip(SC2) of the access requested end entity (accessed EE). This is executedas the public key certificate mutual authentication processing describedwith reference to FIG. 13, for example. In step S205, mutualauthentication is performed between the security chip (SC1) of theaccess requesting user device and the user security chip (USC), and instep S206, mutual authentication is executed between the accessrequesting user security chip (USC) and the security chip (SC2)corresponding to the access requested end entity (accessed EE). In stepS207, a mutual authentication completion notification which includesmutual authentication establishment/non-establishment is output from theaccess requesting user security chip (USC) to the end entity (EE).

Note that the processing of steps S205 through S207 is processingnecessary in the event of issuing a group attribute certificatecorresponding to the access requesting user security chip (USC), and canbe omitted in the event of issuing a group attribute certificatecorresponding to the access requesting security chip (SC1).

In the event that any one of the above mutual authentications is notestablished, continuation of the processing is cancelled. In the eventthat all mutual authentications are established, in step S208 the accessrequesting end entity (EE) presents a group attribute certificate (Gp.AC) which it already holds to the access requested security chip (SC2),and requests issuing of a new group attribute certificate (Gp. AC).

The processing here is an example of processing for verifying a groupattribute certificate (Gp. AC) which the access requester already holdsand issuing a new group attribute certificate (Gp. AC) with differentdefinition. That is to say, conformation of attributes by thealready-existing group attribute certificate (Gp. AC) is included in theissuing policy of the group attribute certificate (Gp. AC) to be newlyissued. For example, confirmation of the identification of the user,confirmation that the device is of a certain manufacturer, or the like,is executed based on the already-existing group attribute certificate(Gp. AC), and issuing processing of the new group attribute certificate(Gp. AC) is performed under the condition that the confirmation can bemade.

An example of an already-existing group attribute certificate (Gp. AC)is a group attribute certificate issued by a credit card company, issuedcorresponding to the user by performing mutual authentication with theuser security chip (USC) of the user identification device (UID), forexample. Another is a group attribute certificate stored in an endentity (EE) as the result of mutual authentication with the securitychip (SC) of an end entity (EE) such as a communication terminal servingas a communication processing device, a PC, or the like, issued by amanufacturer proving that the terminal has been manufactured by themanufacturer.

The security chip (SC2) of the access requested device verifies thealready-issued group attribute certificate received from the end entity(EE) of the access requesting device. This verification processing isthe same processing as that described with reference to FIG. 21 throughFIG. 23 earlier, and is processing including attribute certificatesignature verification, corresponding and chain public key certificateverification, and so forth.

The access requested security chip (SC2) outputs the verificationresults to the access requested end entity (EE), and in the event thatverification is unsuccessful, does not execute subsequent processing butcancels the processing, as error processing. In this case, processingfor transmitting an error notification to the accessing end entity (EE)may be performed.

In the event that verification of the group attribute certificate (Gp.AC) is successful and the authenticity of the group attributecertificate (Gp. AC) has been confirmed, the flow proceeds to step S211.In step S211, screening of the group attribute certificate (Gp. AC) isperformed. Screening is executed based on the group information databasewhich the access requested end entity (EE) holds. This screeningprocessing is processing the same as the processing described withreference to FIG. 25 earlier. That is to say, issuer information andgroup identification information (group ID) is obtained from theverified group attribute certificate (Gp. AC), the group informationdatabase is searched based on the obtained AC issuer and group ID, andwhether or not there is a registered entry is confirmed. In the eventthat there is a corresponding registration entry, the group informationis obtained from the group information database.

In the event that there is no group information registered correspondingto the group attribute certificate (Gp. AC), or in the event that thegroup information conditions are not satisfied, the screening isunsuccessful, and the processing is canceled as an error. On the otherhand, in the event that screening is successful, in step S212 a newgroup attribute certificate generating request is output to the securitychip (SC2) following the request, the security chip (SC2) generates thegroup attribute certificate following the request in step S213, and instep S214 the new group attribute certificate (Gp. AC) is issued fromthe accessed end entity (EE) to the user identification device (UID) ofthe accessing user device.

In the event that the access requesting user device is, for example, acommunication terminal device such as a PC storing secure information ofa company B, the newly-issued group attribute certificate willcorrespond to attributes such as

“attribute of ‘employee of company B’, issued from company B to UID”,

“attribute of ‘member of project C’, issued from company B to UID”,

or the like.

The access requesting user device which is a communication terminaldevice such as a PC storing secure information of company B can requestpresentation of a group attribute certificate at the time of an accessrequest from an indeterminate user device, executes verification andscreening of the presented group attribute certificate, and determinewhether or not access is permissible.

Next, an issuing processing sequence of a group attribute certificatehaving access permission information as an attribute will be describedwith reference to FIG. 30. In FIG. 30, steps S221 through S235correspond to step S201 through S215 in FIG. 29, and the processingthereof is the same.

In FIG. 30, in step S228 the group attribute certificate which theaccess requesting end entity (accessing EE) presents to the securitychip (SC2) of the access requested user device is a certificate having“attribute of ‘employee of company B’, issued from company B to UID”,and the security chip (SC2) of the access requested user device executesverification and screening of this attribute certificate and issues anew group attribute certificate, i.e., a certificate having as theattribute, attribute information permitting access to the device (accessrequested user device).

Now, in the event that proof by another group attribute certificatebesides the “attribute of ‘employee of company B’, issued from company Bto UID” is necessary as conditions for issuing the certificate havingthe attribute information which is group information permitting accessto the device (access requested user device), the processing of stepsS228 through S231 is repeated as many times as the number of groupattribute certificates necessary.

An example of correlation between a group attribute certificate havingaccess permission information as group information, and another groupattribute certificate, will be described with reference to FIG. 31. In(a), a group attribute certificate having access permission informationas group information corresponds to a group δ, and the condition forissuing a group attribute certificate corresponding to this group δ forexample is being a member of a group α. Being a member of the group αcan be proved with the group attribute certificate proving the“attribute of ‘employee of company B’, issued from company B to UID”,and the group attribute certificate corresponding to the group δ isissued under the condition that the group attribute certificate provingmembership of the group α has been presented and that the verificationand screening thereof have succeeded.

In FIG. 31(b), a group attribute certificate having access permissioninformation as group information corresponds to the group δ, and thecondition for issuing a group attribute certificate corresponding tothis group δ for example is satisfying all of the conditions of being amember of the group α, being a member of a group β, and being a memberof a group γ.

Specifically, the setting is that the group attribute certificate isissued having access permission information corresponding to the group δas group information upon presenting and verification of three groupattribute certificates; a group attribute certificate α (group α)proving that the residence of the user belongs to a certain region, agroup attribute certificate β (group β) indicating that the user deviceis a device of a certain manufacturer; and a group attribute certificateγ (group γ) indicating that the age of the user is within a certainrange.

By issuing a group attribute certificate to a user identification deviceserving as an individual identification device making up an accessrequesting device, access can be permitted in screening based on thegroup attribute certificate issued to the user identification deviceserving as the individual identification device even in the event thatthe end entity (EE) which is the communication processing device hasbeen changed, thereby preventing cases wherein access is denied due tochanging the communication processing device (end entity (EE)).

Next, the processing sequence executed for an access requested userdevice to not execute the attribute certificate issuing processingitself but commission the attribute certificate issuing processing toanother user device will be described with reference to FIG. 32. In FIG.32,

UID: access-requesting user identification device (user device) controlunit,

USC: access-requesting user security chip configured within the UID,

Access-requesting EE: access-requesting end entity (user device) controlunit,

SC1: security chip configured within the access-requesting EE,

Access-requested EE: access-requested end entity (user device) controlunit,

SC2: security chip configured within the access-requested EE, and

Other EE: third user device (procedure agent user device) SC3: securitychip of other EE.

In FIG. 32, steps S241 through S248 correspond to steps S201 through 208in FIG. 29, and the processing is the same, so description will beomitted. In step S248, the access requested user device end entity(accessed EE) transfers the group attribute certificate presented fromthe access requesting end entity (accessing EE) to the security chip(SC3) of a procedure agent user device, the security chip (SC3) executesthe verification (S250) of the transferred group attribute certificate,and the end entity (other EE) of the procedure agent user device furtherexecutes screening (S252) based on the verification result notification(S251).

Further, under the condition that verification and screening has beensuccessful, a group attribute certificate generating request is outputto the security chip (SC3) (S253), in step S254 the security chip (SC3)generates a group attribute certificate according to the request, instep S255 a new group attribute certificate (Gp. AC) is issued to theuser identification device (UID) of the access requesting user devicefrom the procedure agent end entity (other EE), and in step S257 theuser identification device (UID) of the access requesting user devicestores the received group attribute certificate.

The processing sequence shown in FIG. 32 is a configuration wherein, inthe event that the access requested user device does not have attributecertificate verification, screening and issuing functions, a thirddevice can be commissioned to carry out these processes. Note that theprocedure agent user device may be configured of a service provider (SP)or the like.

Next, the service usage sequence having access permitted/not-permitteddetermining processing, using a group attribute certificate whereinaccess permission information is defined as group information, will bedescribed with reference to FIG. 33.

First, in step S261, an access request command which is group attributecertificate (Gp. AC) usage processing, is input by the access requestinguser via the input interface of the end entity (accessing EE).

Upon the end entity (accessing EE) receiving the request from the user,in step S262 the end entity (accessing EE) makes a connection request tothe access requested end entity (accessed EE), and on the other hand, instep S263, outputs a mutual authentication start request to the securitychip (SC1) within the accessing end entity (accessing EE).

In step S264, mutual authentication is performed between the securitychip (SC1) of the access requesting user device and the security chip(SC2) of the access requested end entity (accessed EE). This is executedas the public key certificate mutual authentication processing describedwith reference to FIG. 13, for example. In step S265, mutualauthentication is performed between the security chip (SC1) of theaccess requesting user device and the user security chip (USC), and instep S266, mutual authentication is executed between the accessrequesting user security chip (USC) and the security chip (SC2)corresponding to the access requested end entity (accessed EE). In stepS267, a mutual authentication completion notification which includesmutual authentication establishment/non-establishment is output from theaccess requesting user security chip (USC) to the end entity (EE).

Note that the processing of steps S265 through S267 is processingnecessary in the event of using a group attribute certificatecorresponding to the access requesting user security chip (USC), and canbe omitted in the event of using a group attribute certificatecorresponding to the access requesting security chip (SC1).

In the event that any one of the above mutual authentications is notestablished, continuation of the processing is cancelled. In the eventthat all mutual authentications are established, in step S268 the accessrequesting end entity (EE) presents a group attribute certificate (Gp.AC) to the access requested security chip (SC2), and requests accesspermission.

The security chip (SC2) of the access requested device verifies thegroup attribute certificate received from the access requesting endentity (EE) (S269). This verification processing is the same processingas that described with reference to FIG. 21 through FIG. 23 earlier, andis processing including attribute certificate signature verification,corresponding and chain public key certificate verification, and soforth.

The access requested security chip (SC2) outputs the verificationresults to the access requested end entity (EE) (S270), and in the eventthat verification is unsuccessful, does not execute subsequentprocessing but cancels the processing, as error processing. In thiscase, processing for transmitting an error notification to the accessingend entity (EE) may be performed.

In the event that verification of the group attribute certificate (Gp.AC) is successful and the authenticity of the group attributecertificate (Gp. AC) has been confirmed, the flow proceeds to step S271.In step S271, screening of the group attribute certificate (Gp. AC) isperformed. Screening is executed based on the group information databasewhich the access requested end entity (EE) holds. This screeningprocessing is processing the same as the processing described withreference to FIG. 25 earlier. That is to say, issuer information andgroup identification information (group ID) is obtained from theverified group attribute certificate (Gp. AC), the group informationdatabase is searched based on the obtained AC issuer and group ID, andwhether or not there is a registered entry is confirmed. In the eventthat there is a corresponding registration entry, the group informationis obtained from the group information database. The group informationincludes information such as for example, “access permitted to thisdevice” or “only data readout permitted” or the like, and services areprovided following this information.

In the event that there is no group information registered correspondingto the group attribute certificate (Gp. AC), or in the event that thegroup information conditions are not satisfied, the screening isunsuccessful, and the processing is canceled as an error. On the otherhand, in the event that screening is successful, in step S272 serviceproviding is permitted, i.e., access to a service registered as groupinformation, e.g., a device, is permitted.

[(5) Specific Usage Examples of Group Attribute Certificate]

(5-1) Content Distribution Service

(5-2) Remote Control Service

(5-3) Remote Maintenance Service

(5-4) Personal Communication Service

These usage arrangements will each be described.

FIG. 34 shows an example of group attribute certificates used for thevarious services. FIG. 34 illustrates the group attribute certificateissuer, issuing timing, holder, verifier, and attribute, in a correlatedmanner. As described above, the issuer may be a variety of issuingentities besides a group ARA which only performs group attributecertificate issuing processing, such as a service provider, user device,etc, and examples of a service provider include “card company A” whichissues credit cards, a certain organization, such as “company B” or“City hall”, an individual user “Mr. A”, “EE manufacturer C” whichmanufactures end entities (EE) such as PCs, communication terminals,game devices, and so forth.

The timing for issuing the group attribute certificate may be set tovarious timings, such as an arbitrary timing, at the time of purchasing,manufacturing, or after purchasing, the end entity (EE) such as a PC,communication terminal, game device, or the like, according to theservice to be provided based on the certificate.

The holder of the group attribute certificate is a user or a user devicewhich is a member of a certain group, and a group attribute certificateissued with a user, “Mr. A” for example, as the holder thereof, isissued based on authentication of the user security chip (USC) of theuser identification device (UID) of Mr. A, to the user security chip(USC), and group attribute certificates issued to the members of afamily, for example, are issued based on authentication of the usersecurity chips (USC) of the user identification devices (UID) of thefamily members, to the user security chips (USC), and group attributecertificates provided to user devices such as PCs, communicationterminals, game devices, etc., are issued based on authentication of theuser security chip (USC), to the security chip (SC) of the end entity(EE).

The executer of the verification processing of these group attributecertificates is the security module (SM) of the service provider (SP)which provides the services based on attributes proven by the groupattribute certificates, or, though not shown in the drawings, thesecurity chips (SC, USC) of user devices.

Examples of the holder attributes proven by the group attributecertificates include “card company A member”, “employee of company B”,“family of Mr. A”, “registered user”, “registered user device”, “device(EE) of group attribute certificate issuer”, “device (EE) of Mr. A”, andso forth, with the above attributes being proved regarding thepresenting user or presenting device of the group attribute certificate,through verification and screening of the group attribute certificate.The group attribute certificate verifier such as a service provider orthe like provides predetermined services based on the proven holderattributes.

(5-1) Content Distribution Service

First, description will be made regarding a content distribution serviceusing a group attribute certificate. There are various arrangements forconfirming the usage privileges for contents in content distributionapplying group attribute certificates.

First, as one example, description will be made regarding a processingexample wherein, based on a first group attribute certificate A provingthat a user is a member holding a credit card issued by a credit cardcompany, a second group attribute certificate B is issued by a contentdistribution service provider which is a content distribution serviceentity including content usage permission information as groupinformation, and the second group attribute certificate B is applied toexecute confirmation of the content usage privileges, upon which thecontent distribution service is carried out.

The processing for issuing the second group attribute certificate Bincluding the content usage privilege as group information will bedescribed, based on the first group attribute certificate A proving thatthe user device is a credit card member, with reference to FIG. 35.

In the example in FIG. 35, the first group attribute certificate Aissued to the user security chip (USC) of the user identification device(UID) proving credit card membership is presented to a group attributecertificate registration authority (Gp. ARA), and a group attributeauthority (Gp. AA) issues the second group attribute certificate B ofwhich the content distribution service provider is the issuing entity.Here, the content distribution service provider is assumed to haveagreed with the group attribute certificate registration authority (Gp.ARA) on group attribute certificate issuing policies.

In FIG. 35,

UID: user identification device (user device) control unit,

USC: user security chip configured within the UID,

EE: end entity (user device) control unit,

SC: security chip configured within the EE,

Group ARA: group attribute certificate registration authority controlunit, and

Group AA: group attribute authority control unit.

First, in step S301, the user inputs a group attribute certificate (Gp.AC) issuing request command via the input interface of the end entity(EE). At this time, the user inputs an attribute value which isnecessary for issuing the group attribute certificate. The attributevalue is a group ID, or information proving belonging to the group.

Upon receiving the group attribute certificate (Gp. AC) issuing requestinput from the user of the end entity (EE), in step S302 mutualauthentication is performed between the user security chip (USC) and thegroup ARA. Though omitted here, at this time, establishment of all of:

(1) Mutual authentication between the SC of the EE and the group ARA,

(2) Mutual authentication between the SC of the EE and the USC of theUID, and

(3) Mutual authentication between the USC of the UID and the group ARA,

for example, is performed in order for mutual authentication to becarried out between the user identification device (UID) having nodirect communication functions with the group ARA. Or as a simplerconfiguration, a processing configuration may be made wherein the EEbasically accepts (deems authenticated) the UID upon connection to theEE, and in this case, the mutual authentication (2) above can beomitted. Further, authentication configurations under differentcombinations of the above three types can be realized.

The authentication processing is executed primarily as enciphermentprocessing at the encipherment processing units (see FIG. 9) of thesecurity chips in the respective devices, such as public key mutualauthentication processing described with reference to FIG. 13 earlier,for example. In step S303, a mutual authentication completionnotification, including results information of mutual authenticationestablished/not-established, is output from the user security chip (USC)to the end entity. In the event that mutual authentication is notestablished, continuation of processing is cancelled. In the event thatmutual authentication is established, in step S304, the end entity (EE)transmits a group attribute certificate (Gp. AC) issuing request to thegroup ARA. The group attribute certificate (Gp. AC) issuing requestincludes end entity information and attribute information (e.g., groupID, group information), and further, includes the first group attributecertificate A proving being a credit card member, to be presented as acondition for issuing the second group attribute certificate B of whichthe content distribution provider is the issuing entity.

After verifying the first group attribute certificate A proving being acredit card member, the group ARA which has received group attributecertificate (Gp. AC) issuing request from the end entity (EE) makesreference to the issuing policy table in step S305 to determine whetheror not a group attribute certificate can be issued compliant with thepolicies, and if this is permissible the flow proceeds to step S306, andif not permissible, the end entity is notified with a issuingnot-permissible message.

In step S306, the group ARA transmits a group attribute certificate (Gp.AC) issuing request having an attribute value (group ID) to the groupAA, and in step S307, the group AA stores the group ID as attributeinformation, generates the group attribute certificate affixed with theelectronic signature, i.e., the second group attribute certificate Bincluding content usage permission information as group information, andtransmits this to the group ARA.

In step S308, the group ARA transmits the issued group attributecertificate (Gp. AC) to the user identification device (UID). The useridentification device (UID) stores the group attribute certificate (Gp.AC) that has been received. At this time, verification of the electronicsignature of the group attribute certificate (Gp. AC) is performed, andafter confirming that there has been no tampering, is stored in memory.

Next, with reference to FIG. 36, description will be made regardingprocessing wherein the group attribute certificate B issued by the aboveprocessing, i.e., the second group attribute certificate B includingcontent usage permission information as group information, is presentedto the service provider, confirmation is made that there are contentusage privileges, and providing of service, i.e., content distributionservices, is received. In FIG. 36,

UID: user identification device (user device) control unit,

USC: user security chip configured within the UID,

EE: end entity (user device) control unit,

SC: security chip configured within the EE,

SP: service provider control unit, and

SM: security module within SP.

Also note that the security chip (SC), the user security chip (USC), andthe security module (SM), have the same configuration as the securitychip described earlier in FIG. 9, and privilege determining processingand the like is performed by verification of the group attributecertificate at the security chip. That is to say, the service providerwhich has received, with a reception unit such as a network interface orthe like, the group attribute certificate sent from the servicerequesting device to the service requested device, hands the receivedgroup attribute certificate to the security module (chip) serving as aprivilege determining processing unit, and privilege determiningprocessing is executed based on the group attribute certificate receivedwithin the security module (chip).

First, in step S311, a user inputs a group attribute certificate (Gp.AC) usage request command via the input interface of the entity (EE). Atthis time, the user specifies he group ID set in the group attributecertificate to be used. However, in the event that a single group ID canbe determined by specifying a certain service, an arrangement may bemade wherein only the service is specified.

Upon the end entity (EE) receiving the group attribute certificate (Gp.AC) usage request input from the user, mutual authentication isperformed between the user security chip (USC) and the security module(SM) of the service provider in step S312. Now, while omitted in theillustration here, in the event that a user identification device (UID)does not have direct communication functions with the service provider(SP), all of:

(1) Mutual authentication between the SC of the EE and the SP-SM,

(2) Mutual authentication between the SC of the EE and the USC of theUID, and

(3) Mutual authentication between the USC of the UID and the SP-SM,

is performed. Or as a simpler configuration, a processing configurationmay be made wherein the EE basically accepts (deems authenticated) theUID upon connection to the EE, and in this case, the mutualauthentication (2) above can be omitted. Further, authenticationconfigurations under different combinations of the above three types canbe realized.

The authentication processing is executed as public key mutualauthentication processing described earlier with reference to FIG. 13,centered on the encipherment processing unit of the security chip andsecurity module. In step S313, a mutual authentication completionnotification including mutual authentication established/not-establishedresult information is output from the security chip to the end entity.In the event that the mutual authentication is not established,continuation of the processing is cancelled. In the event that mutualauthentication is established, in step S314 the user security chip (USC)transmits the group attribute certificate (Gp. AC) stored in its ownmemory to the security module (SM) of the service provider (SP). Thegroup attribute certificate (Gp. AC) is the second group attributecertificate B including the content usage permission informationobtained by the processing described earlier with reference to FIG. 35as group information.

In step S315, the security module (SM) which has received the groupattribute certificate (Gp. AC) from the user security chip (USC)executes group attribute certificate verification processing. Theverification processing of the group attribute certificate is asdescribed earlier with reference to FIG. 21 through FIG. 23, and isexecuted as processing including attribute certificate signatureverification, corresponding public key certificate (PKC) and chainpublic key certificate confirmation processing, and so forth.

Following verification processing of the group attribute certificate(Gp. AC), the security module (SM) outputs the verification results tothe service provider (SP), and in the event that verification is notestablished, providing of services is not executed and the processing iscancelled as error processing. In this case, processing may be performedwherein the end entity is notified to the effect that verification ofthe group AC was not established.

In the event that the verification of the group attribute certificate(Gp. AC) is successful and the authenticity of the group attributecertificate (Gp. AC) has been confirmed, the flow proceeds to step S317.In step S317, screening of the group attribute certificate (Gp. AC)described earlier with reference to FIG. 25 is carried out. Thescreening is executed based on the group information database which theservice provider holds. That is to say, the service provider (SP)obtains the issuer information and group ID from the verified groupattribute certificate (Gp. AC), searches the group information databasebased on the obtained information, and confirms whether or not there isa registered entry. In the event that there is a correspondingregistered entry, the group information is obtained from the groupinformation database.

The group information in this case is group information of the contentusage permission information, e.g., information permitting usage of agame X for 3 months, and so forth. In step S318, the service provider(SP) performs service providing, i.e., distributes the game program witha 3-month usage period set therein, to the end entity (EE) of the userdevice in accordance with the group information.

While the above-described content distribution service processing is anexample of performing content usage privilege confirmation with onegroup attribute certificate, a processing example will be described nextregarding a case of providing service upon confirming the content usageprivilege of a user or user device, applying multiple different groupattribute certificates proving different group attributes.

FIG. 37 illustrates the multiple group attribute certificates to beapplied in the present example. A group attribute certificate (Gp. AC)AC01 is issued by university A, and is a student ID card proving thatthe holder is a student at university A, and is a group attributecertificate (Gp. AC) issued based on authentication with the usersecurity chip (USC) of the user identification device (UID) of C. Agroup attribute certificate (Gp. AC) AC02 is issued by university A, andis an art class participant card proving that the holder has privilegesto take art classes, and is a group attribute certificate (Gp. AC)issued based on authentication with the user security chip (USC) of theuser identification device (UID) of C.

The group attribute certificate (Gp. AC) AC03 is issued by university A,and is a managed device certificate proving that the device is a devicemanaged by university A, and is a group attribute certificate (Gp. AC)issued based on authentication with the security chip (SC) of atelevision set D serving as an end entity (EE). A group attributecertificate (Gp. AC) AC04 is issued by the Ministry of Education,Culture, Sports, Science and Technology, and is a educational devicecertificate proving that the device is a device for educational use, andis a group attribute certificate (Gp. AC) issued based on authenticationwith the security chip (SC) of a television set D serving as an endentity (EE).

The content usage privilege confirmation and service providingprocessing applying these four different group attribute certificatesAC01 through AC04 will be described with reference to FIG. 38.

FIG. 38 shows the user device side processing to the left and theservice provider side processing to the right. Note that the user deviceincludes the end entity (EE), the security chip (SC) within the EE, theuser identification device (UID), and the user security chip (USC)within the UID.

In steps S321 and 331, mutual authentication processing is executedbetween the user device and service provider. Note that the mutualauthentication is executed according to the device to which the groupattribute certificate to be presented has been issued, with mutualauthentication between either one or both of the SC of the EE and theSP-SM, and the USC of the UID and the SP-SM being carried out.

In the case of the present embodiment, of the four group attributecertificates shown in FIG. 37, AC01 and AC02 have been issued to theuser security chip (USC) of the user identification device (UID) of C,and AC03 and AC04 have been issued to the security chip (SC) configuredin the television set D serving as the end entity (EE), so theprocessing consists of the user identification device (UID) ff Cconnecting to the television set D serving as the end entity (EE) viathe connected device interface 231 (see FIG. 9), connecting to thesecurity module (SM) of the service provider (SP) via the networkinterface 232 (se FIG. 9) of the television set D serving as the endentity (EE), and performing mutual authentication between the SC of theEE and the SP-SM, and mutual authentication between the USC of the UIDand the SP-SM.

The authentication processing is executed as public key mutualauthentication processing described earlier with reference to FIG. 13,centered on the encipherment processing unit of the security chip andsecurity module. In the event that the mutual authentication is notestablished, continuation of the processing is cancelled. In the eventthat mutual authentication is established, in step S322 the devicetransmits the multiple group attribute certificates (Gp. AC) AC01through AC04 stored in its own memory to the security module (SM) of theservice provider (SP). The group attribute certificates (Gp. AC) AC01through AC04 are the four types of group attribute certificates shown inFIG. 37.

At the time of providing services, the combined data of the groupattribute certificates necessary may be of a configuration notified fromthe service provider side to the user side. The service provider holdsgroup attribute certificate combination table data set as the serviceproviding conditions shown in FIG. 39, for example. In the example shownin FIG. 39, data is stored indicating that in order to view the contentB which is a service, the group attribute certificate which is a studentID card issued by the university A, the group attribute certificateindicating which is an education device certificate issued by theMinistry of Education, Culture, Sports, Science and Technology arenecessary, and this table is applied to notify the user device regardingpresentation of necessary group attribute certificates.

In step S332, the security module (SM) which has received the four typesof group attribute certificates (Gp. AC) AC01 through AC04 necessary forproviding the services FROM the user device in this example sequentiallyselects one group attribute certificate from the multiple groupattribute certificates in step S333, and executes verificationprocessing. The group attribute certificate verification processing isas described earlier with reference to FIG. 21 through FIG. 23, and isexecuted as processing including attribute certificate signatureverification, corresponding public key certificate (PKC) and chainpublic key certificate confirmation processing, and so forth.

Following verification processing of the group attribute certificate(Gp. AC), in the event that verification is not established (No inS334), providing of services is not executed and the processing iscancelled as error processing (S339). In this case, processing may beperformed wherein the end entity is notified to the effect thatverification of the group AC was not established.

In the event that the verification of the group attribute certificate(Gp. AC) is successful (Yes in S334) and the authenticity of the groupattribute certificate (Gp. AC) has been confirmed, the flow proceeds tostep S335. In step S335, screening of the group attribute certificate(Gp. AC) described earlier with reference to FIG. 25 is carried out. Thescreening is executed based on the group information database which theservice provider holds. That is to say, the service provider (SP)obtains the issuer information and group ID from the verified certifiedgroup attribute certificate (Gp. AC), searches the group informationdatabase based on the obtained information, and confirms whether or notthere is a registered entry. In the event that there is a correspondingregistered entry, the group information is obtained from the groupinformation database. The group information in this case is informationincluding content distribution permission information.

In the event that screening of a group attribute certificate fails (Noin S336), for example, in the event that obtaining the group informationhas failed, the service provided is not carried out and the processingis cancelled, as error processing (S339). In this case, processing fornotifying the end entity to the effect that verification of the group ACwas not established may be performed.

In the event that screening of the group attribute certificate isestablished (Yes in S336), and the flow proceeds to step S337,determination is made regarding whether verification and screening ofall presented group attribute certificates has ended, and in the eventthat not all has ended, the verification and screening processing fromstep S333 on is executed for the group attribute certificate which hasnot been finished.

In the event that determination is made in step S337 that allverification and screening has ended for the presented group attributecertificates, in step S338 the service is executed, and the user deviceexecutes service reception in step S340. Specifically, the user C canview the distributed content on the television set D (see FIG. 37) whichis the end entity.

A model diagram of the usage privilege confirmation processing applyingthe multiple group attribute certificates described above is shown inFIG. 40. That is to say, illustrating the definition regions of thegroup attribute certificates defining four different types of attributeswith the groups AC01 through AC04 in FIG. 40, in order for usageprivileges of the above content to be permitted, there is the need asshown in (a) for user group attributes to belong to both groups of thestudent ID card (group attribute certificate (AC01)) and art classparticipant card (AC02) and as shown in (b) for device group attributesfor the device used to satisfy the conditions of holding both themanaged device certificate and educational device certificate as devicegroup attributes.

Proof of belonging to both groups of the student ID card (groupattribute certificate (AC01)) and art class participant card (AC02) asuser group attributes shown in (a) is confirmed by verification andscreening of group attribute certificates corresponding to the usersecurity chip (USC) of the user identification device (UID), and proofof being a device holding the managed device certificate and educationaldevice certificate as device group attributes shown in (b) is confirmedby verification and screening of group attribute certificatescorresponding to the security chip (SC) of the end entity (EE).

Note that with the flow described with reference to FIG. 39, processingis performed for providing service under the condition that verificationand screening of four group attribute certificates is successful, butinstead of for providing service under the condition that verificationand screening of four group attribute certificates is successful,processing can be performed wherein a new group attribute certificate isissued for permitting providing of the service, the user presents anewthis one newly-issued group attribute certificate, and verificationthereof enables the service to be provided.

Note however that in this case, the group attribute certificate newlyissued defines both groups of the user group and device group, so a useridentification device (UID) matching the group definition is set to adevice (EE) matching the group definition, and authentication of theuser security chip (USC) of the UID is established by mutualauthentication between the user security chip (USC) of the UID and thesecurity module (SM) of the service provider (SP), and further,authentication of the security chip (SC) is established by mutualauthentication between the security chip (SC) of the end entity (EE) andthe security module (SM) of the service provider (SP). Further,verification and screening being established for the above-describednewly-issued group attribute certificate is a condition for using theservice.

(5-2) Remote Control Service

Next, a service usage example for executing remote control of a devicewhich is an end entity (EE), by executing privilege confirmation, as anexample of a data processing system configuration based on groupattribute certificates.

Here, a medical processing example will be described, wherein a medicaldevice is an end entity (EE), with a medical device installed in thehome and a hospital-side medical device (SP) serving as a serviceprovider performing communication, so that the hospital-side medicaldevice (SP) transmits commands, based upon which medical diagnosis andtests and the like of the user are performed by the medical device (EE)installed in the home, and obtained information such as testing data andthe like is transmitted from the medical device (EE) installed in thehome to the hospital-side medical device (SP)

At the time of executing each processing in the data processing systemfor carrying out the above medical processing, processing for confirmingwhether or not the processing can be made based on verification andscreening of the group attribute certificates for each, and followingexecution permitted/not-permitting confirmation being made, varioustypes of data processing relating to medical processing produces arecarried out. An example of group attribute certificates to be applied isshown in FIG. 41.

The issuer of the group attribute certificate AC01 is the hospital-sidemedical device serving as the service provider (SP), and the holder,i.e., the holder which is the object of issuing the group attributecertificate by performing authentication processing with thehospital-side medical device (SP) which is the issuer of the groupattribute certificate AC01 at the time of issuing, is the user securitychip (USC) of the user identification device (UID) of Mr. A who is toreceive medical services by means of the home-side medical device (EE).Or, this may be the security chip (SC) of the home-side medical device(EE).

The group attribute certificate AC01 is applied at the time ofconfirmation processing for determining whether or not the medicalprogram can be executed, and is sent to the hospital-side medical device(SP) from the USC or the SC of the user device which is the holder, andfollowing verification and screening of the group attribute certificateAC01, the service, i.e., running the medical diagnosis program, ispermitted with the hospital-side medical device (SP).

The issuer of the group attribute certificate AC02 is the home-sidemedical device (EE), and the holder, i.e., the holder which is theobject of issuing the group attribute certificate by performingauthentication processing with the home-side medical device (EE) whichis the issuer, at the time of issuing the group attribute certificateAC02, is the security module (SM) of the hospital-side medical deviceserving as the service provider (SP).

The group attribute certificate AC02 obtained from the subject ofdiagnosis (Mr. A) by executing the medical diagram, and is applied atthe time of processing for determining whether or not processing can beperformed wherein diagnosis data such as, for example, blood pressurevalues, pulse, blood sample data, etc., is transmitted from thehome-side medical device (EE) to the hospital-side medical device (SP).

The group attribute certificate AC02 is sent from the hospital-sidemedical device (SP) to the home-side medical device (EE), and followingverification and screening of the group attribute certificate AC02 atthe home-side medical device (SP), service, providing of the service,i.e., sending processing of the medical diagnosis result data isperformed.

Note that while the issuing processing of the group attributecertificates AC01 and AC02 can be issued from the hospital-side medicaldevice (SP) or home-side medical device (EE), or user identificationdevice (UID) itself, serving as the group attribute authority (group AA)and group attribute certificate registration authority (group ARA), buta configuration can also be made wherein the group attribute authority(group AA) and group attribute certificate registration authority (groupARA) are commissioned to carry out the issuing processing. However, inthis case, performing processing following the policies of the issuer isa condition.

For example, regarding issuing processing of the group attributecertificate AC01, a preferable method is for the hospital-side medicaldevice (SP) which is the issuer, or the group attribute certificateregistration authority (group ARA) which is an issuing agent, causes Mr.A who is the subject of medical diagnosis to present an already-issuedgroup attribute certificate proving that the user is Mr. A, such as agroup attribute certificate issued by a credit card company for example,and following verifying the presented group attribute certificate, toperform issuing processing of a new group attribute certificate AC01.The processing sequence for issuing a new group attribute certificate onthe condition of verification of such an already-issued group attributecertificate is the same as the processing sequence described earlierwith reference to FIG. 29, FIG. 30, FIG. 32, etc.

Also, in the same way, regarding issuing processing of the groupattribute certificate AC02, a preferable method is for the home-sidemedical device (EE) which is the issuer, or the group attributecertificate registration authority (group ARA) which is an issuingagent, causes the hospital-side medical device (SP) to present analready-issued group attribute certificate proving that it is thehospital-side medical device (SP), such as a group attribute certificateissued by a manufacturer or public managing organization for example,and following verifying the presented group attribute certificate, toperform issuing processing of a new group attribute certificate AC02.

In the remote control system which performs medical processing, thegroup attribute certificates to be stored in the devices are as shown inFIG. 42. The hospital-side medical device (SP) 401 serving as theservice provider, and the home-side medical device (EE) 411 serving asthe end entity are capable of mutually transferring data over acommunication network, and the home-side medical device (EE) 411 and theuser identification device (UID) 421 are capable of mutuallytransferring data via their respective connected device interfaces 231(see FIG. 9).

Each of the devices are provided with a (user) security chip 412, 423,or security module 403, having an anti-tampering configuration, forexecuting mutual authentication processing or encipherment anddecipherment of transferred data and the like at the time of datacommunication processing. Also, the verification processing of the groupattribute certificates is carried out by the (user) security chips 412,423, or security module 403.

The user identification device 421 stores the group attributecertificate AC01, 422 described earlier with reference to FIG. 41. Theissuer of the group attribute certificate AC01, 422 is the hospital-sidemedical device (SP) 401 serving as a service provider, and is appliedfor confirmation processing for determining whether or not the medicalprogram can be executed, is sent from the user device USC 421 which isthe holder to the hospital-side medical device (SP) 401, and followingverification and screening of the group attribute certificate AC01 atthe security module (SM) 403 of the hospital-side medical device (SP)401, the service is provided, i.e., the medical diagnosis program isexecuted.

Also, the hospital-side medical device (SP) 401 serving as the serviceprovider stores the group attribute certificate AC02, 402. With theissuer of the group attribute certificate AC02, 402 the issuer is thehome-side medical device (EE) 411, the holder is the hospital-sidemedical device (SP) 401, and is sent from the hospital-side medicaldevice (SP) to the home-side medical device (EE), and before theprocessing for sending the diagnosis data obtained from the diagnosissubject (Mr. A) from the home-side medical device (EE) 411 to thehospital-side medical device (SP) 401, verification and screening of thegroup attribute certificate AC02, 402 is performed at the security chip(SC) 412 of the home-side medical device (EE), and the transmission ofthe diagnosis results data is executed under the condition that theverification and screening is successful.

The processing sequence for applying the group attribute certificateAC01, 422 stored in the user identification device 421 to perform usageprivilege confirmation processing of the execution service of themedical diagnosis program, and start the service, will be described withreference to FIG. 43. In FIG. 43,

UID: user identification device (user device) control unit,

USC: user security chip configured within the UID,

EE: home-side medical device (EE) control unit,

SC: security chip configured within the EE,

SP: hospital-side medical device (SP) control unit, and

SM: security module within SP.

Also note that the security chip (SC), the user security chip (USC), andthe security module (SM), have the same configuration as the securitychip described earlier in FIG. 9, and privilege determining processingand the like is performed by verification of the group attributecertificate at the security module or chip. That is to say, the serviceprovider or user device which has received, with a reception unit suchas a network interface or the like, the group attribute certificate sentfrom the data processing requesting device to the data processingrequested device, hands the received group attribute certificate to thesecurity module (chip) serving as a privilege determining processingunit, and privilege determining processing is executed based on thegroup attribute certificate received within the security module (chip),with various types of data processing being executed based ondetermination of privileges.

First, in step S321, a user inputs a group attribute certificate (Gp.AC)=AC01 usage request command via the input interface of the home-sidemedical device (EE) serving as the end entity. This group attributecertificate (Gp. AC) is the AC01 shown in FIG. 41 and FIG. 42. At thistime, the user specifies the group ID set in the group attributecertificate AC01 to be used. However, in the event that a single groupID can be determined by specifying a certain service, an arrangement maybe made wherein only the service is specified.

Upon the home-side medical device (EE) receiving the group attributecertificate (Gp. AC) AC01 usage request input from the user, mutualauthentication is performed between the user security chip (USC) and thesecurity module (SM) of the hospital-side medical device (SP) serving asthe service provider (SP) in step S322. Now, while omitted in theillustration here, in the event a user identification device (UID) doesnot have direct communication functions with the SP, all of:

(1) Mutual authentication between the SC of the EE and the SP-SM,

(2) Mutual authentication between the SC of the EE and the USC of theUID, and

(3) Mutual authentication between the USC of the UID and the SP-SM,

is performed. Or as a simpler configuration, a processing configurationmay be made wherein the EE basically accepts (deems authenticated) theUID upon connection to the EE, and in this case, the mutualauthentication (2) above can be omitted. Further, authenticationconfigurations under different combinations of the above three types canbe realized.

The authentication processing is executed as public key mutualauthentication processing described earlier with reference to FIG. 13,centered on the encipherment processing unit (see FIG. 9) of thesecurity chip and security module. In step S323, a mutual authenticationcompletion notification including mutual authenticationestablished/not-established result information is output from the usersecurity chip to the end entity. In the event that the mutualauthentication is not established, continuation of the processing iscancelled. In the event that mutual authentication is established, instep S324 the user security chip (USC) transmits the group attributecertificate (Gp. AC) AC01 stored in its own memory to the securitymodule (SM) of the service provider (SP). The group attributecertificate (Gp. AC) AC01 is the group attribute certificate AC01applied to processing for determining service receiving right privilegesfor the medical program, as described with reference to FIG. 41 and FIG.42.

In step S325, the security module (SM) of the hospital-side medicaldevice (SP) which has received the group attribute certificate (Gp. AC)AC01 from the user security chip (USC) executes group attributecertificate verification processing. The verification processing of thegroup attribute certificate is as described earlier with reference toFIG. 21 through FIG. 23, and is executed as processing includingconfirmation processing of attribute certificate signature verification,corresponding public key certificate (PKC) and chain public keycertificate confirmation processing, and so forth.

Following verification processing of the group attribute certificate(Gp. AC), the security module (SM) outputs the verification results tothe hospital-side medical device (SP), and in the event thatverification is not established, providing of services is not executedand the processing is cancelled as error processing. In this case,processing may be performed wherein the end entity is notified to theeffect that verification of the group AC was not established.

In the event that the verification of the group attribute certificate(Gp. AC) is successful and the authenticity of the group attributecertificate (Gp. AC) has been confirmed, the flow proceeds to step S327.In step S327, screening of the group attribute certificate (Gp. AC)described earlier with reference to FIG. 25 is carried out. Thescreening is executed based on the group information database which thehospital-side medical device (SP) serving as the service provider holds.That is to say, the hospital-side medical device (SP) obtains the issuerinformation and group ID from the verified group attribute certificate(Gp. AC) AC01, searches the group information database based on theobtained information, and confirms whether or not there is a registeredentry. In the event that there is a corresponding registered entry, thegroup information is obtained from the group information database.

The group information in this case includes the medical diagnosisprogram execution permission information. In step S328, thehospital-side medical device (SP) serving as the service providerperforms service providing processing, i.e., executes the medicaldiagnosis program following the group information. That is to say, themedical diagnosis processing by remote control is performed, i.e.,execution commands of the diagnosis programs are transmitted to thehome-side medical device (EE) and diagnosis of the user is carried outthrough the home-side medical device (EE).

Next, the processing sequence will be described with reference to FIG.44 for applying the group attribute certificate AC02, 402 stored in thehospital-side medical device (SP) 401 to perform usage privilegeconfirmation processing of the diagnosis data transaction processingservice which is the medical diagnosis program execution results, andstarting the service.

First, in step S331, the user operating the hospital-side system inputsa group attribute certificate (Gp. AC)=AC02 usage request command viathe input interface of the hospital-side medical device (SP). This groupattribute certificate (Gp. AC) is the AC02 shown in FIG. 41 and FIG. 42.At this time, the user operating the hospital-side system specifies thegroup ID set in the group attribute certificate AC02 to be used.However, in the event that a single group ID can be determined byspecifying a certain service, an arrangement may be made wherein onlythe service is specified.

Upon the hospital-side medical device (SP) receiving the group attributecertificate (Gp. AC) AC02 usage request input, mutual authentication isperformed between the user security chip (USC) and the security module(SM) of the hospital-side medical device (SP) serving as the serviceprovider (SP) in step S332. Now, while omitted in the illustration here,in the event a user identification device (UID) does not have directcommunication functions with the SP, all of:

(1) Mutual authentication between the SC of the EE and the SP-SM,

(2) Mutual authentication between the SC of the EE and the USC of theUID, and

(3) Mutual authentication between the USC of the UID and the SP-SM,

is performed. Or as a simpler configuration, a processing configurationmay be made wherein the EE basically accepts (deems authenticated) theUID upon connection to the EE, and in this case, the mutualauthentication (2) above can be omitted. Further, authenticationconfigurations under different combinations of the above three types canbe realized.

The authentication processing is executed as public key mutualauthentication processing described earlier with reference to FIG. 13,centered on the encipherment processing unit (see FIG. 9) of thesecurity chip and security module. In step S333, a mutual authenticationcompletion notification including mutual authenticationestablished/not-established result information is output from thesecurity module (SM) to the hospital-side medical device (SP). In theevent that the mutual authentication is not established, continuation ofthe processing is cancelled. In the event that mutual authentication isestablished, in step S334 the security module (SM) of the hospital-sidemedical device (SP) transmits the group attribute certificate (Gp. AC)AC02 stored in its own memory to the user security chip (USC) of thehome-side medical device side. The group attribute certificate (Gp. AC)AC02 is the group attribute certificate AC02 applied to processing fordetermining service receiving right privileges for the diagnosis resultsdata, as described with reference to FIG. 41 and FIG. 42.

In step S335, the user security chip (USC) which has received the groupattribute certificate (Gp. AC) AC02 from the security module (SM) of thehospital-side medical device (SP) executes group attribute certificateverification processing. The verification processing of the groupattribute certificate is as described earlier with reference to FIG. 21through FIG. 23, and is executed as processing including confirmationprocessing of attribute certificate signature verification,corresponding public key certificate (PKC) and chain public keycertificate confirmation processing, and so forth.

Following verification processing of the group attribute certificate(Gp. AC), the user security chip (USC) outputs the verification resultsto the home-side medical device (EE) (S336), and in the event thatverification is not established, providing of diagnosis resultstransmission services is not executed and the processing is cancelled aserror processing. In this case, processing may be performed wherein thehospital-side medical device (SP) is notified to the effect thatverification of the group AC was not established.

In the event that the verification of the group attribute certificate(Gp. AC) is successful and the authenticity of the group attributecertificate (Gp. AC) has been confirmed, the flow proceeds to step S337.In step S337, screening of the group attribute certificate (Gp. AC)described earlier with reference to FIG. 25 is carried out. Thescreening is executed based on the group information database which thehome-side medical device (EE) holds. That is to say, the home-sidemedical device (EE) obtains the issuer information and group ID from theverified group attribute certificate (Gp. AC) AC02, searches the groupinformation database based on the obtained information, and confirmswhether or not there is a registered entry. In the event that there is acorresponding registered entry, the group information is obtained fromthe group information database.

The group information in this case includes diagnosis resultstransmission permission information of the medical diagnosis program. Instep S338, the home-side medical device (EE) performs service providingprocessing, i.e., executes transmission processing of the diagnosisresults of the medical diagnosis program following the groupinformation. That is to say, processing for transmitting the medicaldiagnosis processing results from the home-side medical device (EE) tothe hospital-side medical device (SP) is performed.

(5-3) Remote Maintenance Service

Next, as a configuration example of a data processing system whichexecutes privilege confirmation based on group attribute certificates toperform data processing, an example of using a service which executesremote maintenance of devices which are end entities (EE), e.g., homeappliances.

Here, description will be made regarding an example wherein various homeappliances such as audio-video equipment, air conditioners,refrigerators, and so forth, having communication functions, are endentities (EE), and communication is performed between the homeappliances installed in the home or the like and a service providingdevice (SP) at the manufacturer thereby executing repair, maintenance,upgrading, and other control processing, of the home appliances (EE)installed in the home, based on commands transmitted from the serviceproviding device (SP).

At the time of executing the above-describe processes, processing isperformed for confirming whether or not processing can be carried out,based on verification and screening of each of the group attributecertificates, and following the execution permissible/not-permissibleconfirmation, each process is carried out. FIG. 45 shows an example ofthe group attribute certificates to be applied. The group attributecertificates are classified into two general categories. One is serviceattribute certificate (AC), and the other is control attributecertificate (AC).

With a service attribute certificate (AC), the issuer is a homeappliance manufacturer side device serving as a service provider (SP),and the holder, i.e., the holder which is the object of issuing of theattribute certificate by means of performing authentication processingwith the home appliance manufacturer side device (SP) which is theissuer at the time of issuing the service attribute certificate (AC), isa user security chip (USC) of a user identification device (UID) usingthe home appliance installed in the home, or the security chip (SC) ofthe home appliance (EE).

The service attribute certificate is issued to a home appliancepurchaser group of home appliance group given privileges to receivesubsequent services regarding repair, maintenance upgrade, and othercontrol processing of the home appliance (EE), by the user which haspurchased the home appliance entering into a subscriber contract withthe manufacturer side at the time of purchasing the home appliance.Accordingly, the service attribute certificate is a group attributecertificate issued to a home appliance purchaser group or a homeappliance group.

In the event of issuing to a home appliance purchaser group, issuingprocessing is performed under the condition that mutual authenticationis established between the user security chip (USC) of the useridentification device (UID) and the security module of the homeappliance manufacturer (SP), and in the event of issuing to a homeappliance group, issuing processing is performed under the conditionthat mutual authentication is established between the security chip (SC)of the home appliance (EE) and the security module of the home appliancemanufacturer (SP).

At the time of requesting repair, maintenance, upgrade, or other controlservice of the home appliance (EE), the service attribute certificate issent from the home appliance (EE) or the user identification device(UID) to the manufacturer side device (SP) and following verificationand screening of the group attribute certificate at the manufacturerside device (SP), transition is made to providing of the services.

With a control attribute certificate, the issuer is a home appliance(EE), which receives the repair, maintenance, upgrade, or other controlservice, and the holder, i.e., the holder which is the object of issuingof a group attribute certificate by performing mutual authenticationwith the home appliance (EE) at the time of issuing the controlattribute certificate, is the security module (SM) of the manufactureside device serving as the service provider (SP).

This control attribute certificate is a certificate issued under thecondition of holding a service attribute certificate followingpurchasing the home appliance, between the user which has purchased thehome appliance and the manufacturer side, and is issued, for example,from a user having multiple home appliances of the same manufacture, tothe manufacturer side device which is the service provider,corresponding to each home appliance, as a certificate stating theexecution range of maintenance services for each of the home appliances.Or an arrangement may be made wherein a certificate recording differencecontrol privilege information is issued for one home appliance. Anexample is an attribute certificate permitting only upgrade processingas a received service, to commission software upgrading processing, anattribute certificate permitting only inspecting processing for regularinspections, and so forth, as home appliance control information.

A control attribute certificate is a group attribute certificate ofwhich a plurality can be issued to a home appliance group of multiplehome appliances owned by one user, or to one home appliance. In theevent of issuing to a home appliance group of multiple home appliancesowned by a single user, issuing processing is performed under thecondition of establishment of mutual authentication between the usersecurity chip (USC) of the user identification device (UID) and thesecurity module of the home appliance manufacturer (SP), and in theevent of issuing to one particular home appliance, issuing processing isperformed under the condition of establishment of mutual authenticationbetween the USC of the UID or the security chip (SC) of the particularhome appliance (EE) and the security module of the home appliancemanufacturer (SP).

The control attribute certificate is issued from the user side (EE orUID) and stored in the manufacturer side device providing the service,is transmitted from the manufacturer side device to the user side (EE orUID) at the time of executing repair, maintenance, upgrading, or othercontrol service of the home appliance (EE), and transition is made toproviding the service following verification and screening of thecontrol attribute certificate at the user side (EE or UID).

Issuing of service attribute certificates or control attributecertificates can be performed by the manufacturer side device (SP) orhome appliance (EE) or user identification device (UID) itself executingfunctions of a group attribute authority (AA) and group attributecertificate registration authority (ARA), but a configuration may alsobe made wherein issuing processing is commissioned to a group attributeauthority (AA) and group attribute certificate registration authority(ARA). However, processing following the policies of the issuer beingexecuted is a condition in this case.

For example, issuing processing of a service attribute certificate ispreferably performed by a manufacturer side device (SP) which is theissuer, or a group attribute certificate registration authority (ARA)serving as an issuing agent, causing a user which desires to receive aservice to present, an already-issued group attribute certificate whichproves the identity of the user, such as a group attribute certificateissued from a credit card company, and following verification of thepresented group attribute certificate, a service attribute certificateis issued as a new group attribute certificate, or, wherein a homeappliance is caused to present a group attribute certificate provingthat the home appliance belongs to a product group manufactured by themanufacturer, the group attribute certificate being stored in the homeappliance at the time of manufacturing, and following verification ofthe presented group attribute certificate, issuing processing isperformed for issuing a service attribute certificate as a new groupattribute certificate. As for conditions for verification of analready-issued group attribute certificate in this way, the processingsequence for issuing the new group attribute certificate is the sameprocessing sequence as that described earlier with reference to FIG. 29,FIG. 30, FIG. 32, and so forth.

Also, with the issuing processing for a control attribute certificate, apreferable method is, in the same way, for the home appliance (EE) whichis the issuer or a group attribute certificate registration authority(ARA) serving as an issuing agent to cause the manufacturer side device(SP) to present an already-issued group attribute certificate provingthat it is an authentic device of the manufacture side, such as aservice attribute certificate serving as a group attribute certificateissued by the manufacturer as described above, and followingverification of the presented certificate, issue processing is performedfor the control attribute certificate as a new group attributecertificate.

In a system for performing maintenance services, the attributecertificates stored in the devices are as shown in FIG. 46. Themanufacturer side device (SP) 451 serving as the service provider, andthe user-side home treatment device (EE) 461 serving as the end entityare capable of mutually transferring data by a communication network,and the user side home appliance (EE) 461 and the user identificationdevice (UID) 471 are capable of mutually transferring data by acommunication network via connected device interfaces 231 (see FIG. 9)of each.

Each of the devices have (user) security chips 463 and 472 or securitymodule 453 having anti-tampering configurations, performing mutualauthentication processing at the time of data communication processing,and encipherment and decipherment and the like of the transferred data.Also, verification processing of the group attribute certificate isexecuted at the (user) security chips 463 and 472 or security module453.

The service attribute certificate 462 described above with reference toFIG. 45 is stored in the user side home appliance (EE) 461. The serviceattribute certificate 462 has as the issuer thereof the manufacturerside device (SP) 451 serving as the service provider, is applied toconfirmation processing for determining whether or not it is permissibleto execute home appliance maintenance or repair or the like, and is sentfrom the SC 463 of the user side home appliance (EE) 461 which is theholder to the manufacturer side device (SP) 451. After verification andscreening at the security module (SM) 463 of the manufacturer sidedevice (SP) 451, the service, i.e., transmission of control attributecertificate and maintenance and the like within the privilege rangepermitted by the control attribute certificate is carried out.

The control attribute certificate 452 is stored at the manufacturer sidedevice (SP) 451 serving as the service provider. The control attributecertificate 452 has as the issuer the user side home appliance (EE) 461,the holder thereof is the manufacturer side device (SP) 451, is sentfrom the manufacturer side device (SP) to the user side home appliance(EE) 461, and before executing services such as maintenance or the like,verification and screening of the control attribute certificate isexecuted at the security chip (SC) of the user side home appliance (EE)461, and under the condition that verification and screening has beenestablished, processing such as maintenance, repair, upgrading, etc., isexecuted within the privilege range confirmed by the control attributecertificate.

An arrangement of using a service attribute certificate and controlattribute certificate at the time of executing service is described withreference to FIG. 47. First, a service attribute certificate (AC) 484 ispresented to the manufacturer side device (SP) 482 from a home appliance(EE) which desires to receive service such as maintenance, repair,inspection, upgrading, or the like, or a user identification device(UID) connected to the home appliance. Following verification of theservice attribute certificate at the security module (SM), themanufacturer side device (SP) 482 searches a group information database483 based on the group ID corresponding to the service attributecertificate, extracts a control AC or control AC identification data asgroup data, and obtains a control AC corresponding to the service AC.

The manufacturer side device (SP) 482 transmits the obtained controlattribute certificate (AC) 485 to the home appliance (EE) or the useridentification device (UID) connected to the home appliance, andfollowing verification at the security chip of the home appliance (EE)or user identification device (UID) connected to the home appliance,executes the service such as maintenance or the like to the homeappliance (EE) following control information permitted in the controlattribute certificate (AC).

Note that an execution program for the maintenance, repair, upgrading,etc., may be stored within the home appliance beforehand and used, ormay be transmitted from the manufacturer side to the home appliance sideas necessary to be executed. Preferably, authentication processing, andenciphering processing of the transmitted data is performed at the timeof transmitting the execution program.

Next, with reference to FIG. 48 on, the processing for performing usageprivilege confirmation processing relating to services such asmaintenance and the like of a home appliance using a service attributecertificate stored in the home appliance (EE) which is a user device,and a control attribute certificate stored in the service provider. InFIG. 48,

EE: user side home appliance (EE) control unit,

SC: security chip configured within the EE,

SP: manufacturer-side device (SP) control unit, and

SM: security module within SP.

Also note that the security chip (SC), the user security chip (USC), andthe security module (SM), have the same configuration as the securitychip described earlier in FIG. 9, and privilege determining processingand the like is performed by verification of the group attributecertificate at the security module or chip. That is to say, the serviceprovider or user device which has received, with a reception unit suchas a network interface or the like, the group attribute certificate sentfrom the requesting device requesting service, i.e., data processingsuch as maintenance processing or the like, to the service requesteddevice, hands the received group attribute certificate to the securitymodule (chip) serving as a privilege determining processing unit,privilege determining processing is executed based on the groupattribute certificate received within the security module (chip), andvarious data processing is executed based on a determination that theprivilege is held.

First, in step S341, a user inputs a usage request command for a serviceattribute certificate (AC) which is a group attribute certificate (Gp.AC) via the input interface of the user side home appliance (EE) servingas the end entity. At this time, the user specifies the group ID set inthe service attribute certificate (AC) to be used. However, in the eventthat a single group ID can be determined by specifying a certainservice, an arrangement may be made wherein only the service isspecified.

Upon the user side home appliance (EE) receiving the service attributecertificate (AC) usage request input from the user, mutualauthentication is performed between the security chip (SC) and thesecurity module (SM) of the manufacturer side device (SP) serving as theservice provider in step S342. Note that while the description here isof an example of using a service attribute certificate issued to thesecurity chip (SC) of the home appliance (EE), an arrangement may bemade in the same way using a service attribute certificate issued to thesecurity chip (SC) of the user identification device (UID). However, inthe event a user identification device (UID) does not have directcommunication functions with the SP, all of:

(1) Mutual authentication between the SC of the EE and the SP-SM,

(2) Mutual authentication between the SC of the EE and the USC of theUID, and

(3) Mutual authentication between the USC of the UID and the SP-SM,

is performed. Or as a simpler configuration, a processing configurationmay be made wherein the EE basically accepts (deems authenticated) theUID upon connection to the EE, and in this case, the mutualauthentication (2) above can be omitted. Further, authenticationconfigurations under different combinations of the above three types canbe realized.

The authentication processing is executed as public key mutualauthentication processing described earlier with reference to FIG. 13,centered on the encipherment processing unit of the security chip andsecurity module (see FIG. 9). In step S343, a mutual authenticationcompletion notification including mutual authenticationestablished/not-established result information is output from thesecurity chip to the end entity. In the event that the mutualauthentication is not established, continuation of the processing iscancelled. In the event that mutual authentication is established, instep S344 the security chip (SC) transmits the service attributecertificate stored in its own memory to the security module (SM) of theservice provider (SP) which is the manufacturer side device.

In step S345, the security module (SM) of the manufacturer side device(SP) which has received the service attribute certificate from thesecurity chip (SC) of the user side home appliance executes serviceattribute certificate verification processing. The verificationprocessing of the service attribute certificate is as described earlierwith reference to FIG. 21 through FIG. 23, and is executed as processingincluding attribute certificate signature verification, correspondingpublic key certificate (PKC) and chain public key certificateconfirmation processing, and so forth.

Following verification processing of the service attribute certificate,the security module (SM) outputs the verification results to themanufacturer side device (SP), and in the event that verification is notestablished, providing of services is not executed and the processing iscancelled as error processing. In this case, processing may be performedwherein the end entity is notified to the effect that verification ofthe service AC was not established.

In the event that the verification of the service attribute certificateis successful and the authenticity of the service attribute certificatehas been confirmed, the flow proceeds to step S347. In step S347,screening of the service attribute certificate is carried out. Thescreening is executed based on the group information database which themanufacturer side device (SP) serving as the service provider holds.

Screening processing of the service attribute certificate will bedescribed with reference to FIG. 49. In step S351, the service provider(SP) obtains a group ID as an attribute from the already-verifiedservice attribute certificate. In step S352, the group informationdatabase is searched (S352) based on the group ID obtained from theservice attribute certificate, and control attribute certificateinformation, e.g., the identifier (ID) of the control attributecertificate, is obtained from a registered entry (S353).

As shown in FIG. 49, the group information database (DB) held by theservice provider stores the issuer, group ID of service AC, andcorresponding control attribute certificate information serving as groupinformation such as an ID, in a correlated manner, with the serviceprovider (SP) searching the group information database (DB) based on thegroup ID obtained from the already-verified service attributecertificate (AC) received from the user side home appliance, andobtaining the control attribute certificate (AC) corresponding to theservice AC as group information.

Next, in step S348 (FIG. 48), the manufacturer side device (SP) servingas the service provider obtains the control attribute certificate (AC)based on the ID of the control attribute certificate (AC) obtained fromthe group information database (DB).

Next, description will be made regarding the sequence for executingprocessing for services for a home appliance such as maintenance,inspection, repair, upgrading, control etc., based on the controlattribute certificate, by the service provider which has received theservice attribute certificate, with reference to FIG. 50 on.

In step S370 in FIG. 50, an operator operating the manufacturer sidedevice inputs a maintenance processing execution command applying thecontrol attribute certificate, via an input interface of themanufacturer side device (SP). At the time of this processing, theoperator specifies the group ID set in the control attribute certificateto be used.

Upon the manufacturer side device (SP) receiving the maintenanceprocessing execution request input applying the control attributecertificate, in step S371, mutual authentication between the securitychip (SC) of the home appliance (EE) and the security module (SM) of themanufacturer side device (SP) serving as the service provider isperformed. Note that in the event the service providing sequence basedon the control attribute certificate shown in FIG. 50 is to be carriedout in the same session as the verification processing sequence of theservice attribute certificate described earlier with reference to FIG.48, this mutual authentication processing is unnecessary.

In the event that authentication processing is performed, in step S372,a mutual authentication completion notification including mutualauthentication established/not-established result information is outputfrom the security module (SM) to the manufacturer side device (SP). Inthe event that the mutual authentication is not established,continuation of the processing is cancelled. In the event that mutualauthentication is established, in step S373 the security module (SM) ofthe manufacturer side device (SP) transmits the control attributecertificate extracted based on the received service attributecertificate to the security chip (SC) of the user side home appliance.As described earlier, this control attribute certificate is a groupattribute certificate applied to processing for confirming control rangeprocessing privileges of the home appliance.

The security chip (SC) which has received the control attributecertificate (AC) from the security module (SM) of the manufacturer sidedevice (SP) executes control attribute certificate verificationprocessing in step S374. The control attribute certificate verificationprocessing is as described earlier with reference to FIG. 21 throughFIG. 23, and is executed as processing including attribute certificatesignature verification, corresponding public key certificate (PKC) andchain public key certificate confirmation processing, and so forth.

Following verification processing of the control attribute certificate,the security chip (SC) outputs the verification results to the user sidehome appliance (EE) (step S375), and in the event that verification isnot established (NG in S376), maintenance processing and the like iscancelled as error processing (S377). In this case, processing may beperformed wherein the manufacturer side device (SP) is notified to theeffect that verification of the control attribute certificate was notestablished.

In the event that the verification of the control attribute certificateis successful (OK in S376) and the authenticity of the control attributecertificate has been confirmed, the flow proceeds to step S378. In stepS378, the home appliance (EE) searches for a maintenance executionprogram. The maintenance execution program is a program either stored inmemory of the home appliance (EE) correlated with a control attributecertificate ID or group ID, or is transmitted from the manufacturer sidedevice (SP) at the time of executing processing, and is encipheredbeforehand as necessary. In this sequence diagram, an example is a caseof the a maintenance execution program being stored in memory of thehome appliance (EE) and correlated with a control attribute certificateID or group ID.

In step S379, the enciphered maintenance execution program extracted bythe home appliance (EE) is transferred to the security chip (SC), and instep S380, deciphering processing is executed at the security chip (SC)side. Deciphering processing is executed based on a key provided fromthe service provider (SP) side for example, or a key unique to the userdevice, or the like. Various processing methods can be employed forprogram enciphering formats, such as public key, shared key, and soforth. Also note that a configuration may be used wherein an attributecertificate storing a key may be used to provide the security chip witha key.

In step S381, the maintenance program deciphered from the security chip(SC) is output to the end entity (EE) which is the home appliance, andin step S382, the maintenance program is executed and followingexecution of the program, in step S383 the execution results aretransmitted to the service provider (SP).

FIG. 51 is, like FIG. 50, a sequence for a service provider which hasreceived a service attribute certificate to execute services based on acontrol attribute certificate, i.e., processing such as maintenance,inspection, repair, upgrading, or control of the like, of a homeappliance for example, and is an example wherein the maintenanceexecution program is transmitted from the manufacturer side device (SP)to the user side home appliance (EE). Steps S384 through S392 correspondto steps S370 through S377 in FIG. 50.

In step S393 following verification OK of the control AC, a transmissionrequest for the maintenance program is output from the user side homeappliance (EE) to the manufacturer side device (SP), and in step S394,the manufacturer side device which is the service provider executes themaintenance program search and transmits the searched program to theuser side home appliance (EE) in step S395, which is the difference withthe processing sequence shown in FIG. 50.

Note that the transmitted program is enciphered as necessary.Transmission is made after encipherment with various decipherableformats based on, for example, a session key, a key provided from theservice provider (SP) side, or a key unique to the user device, or thelike. Various processing methods can be employed for program encipheringformats, such as public key, shared key, and so forth. Also note that aconfiguration may be used wherein an attribute certificate storing a keymay be used to provide the security chip with a key.

The processing sequence in FIG. 52 is, like FIG. 50 and FIG. 51, asequence for a service provider which has received a service attributecertificate to execute services based on a control attributecertificate, i.e., processing such as maintenance, inspection, repair,upgrading, or control of the like, of a home appliance for example, andis an example wherein the maintenance execution program is transmittedfrom the manufacturer side device (SP) to the user side home appliance(EE), with responses based on execution of commands being received fromthe user side home appliance (EE) and processing corresponding to theresponses being executed.

Steps S410 through S420 correspond to steps S384 through S394 in FIG.51. With this configuration, the service provider (SP) enciphers thecommands according to the maintenance program as necessary in step S421and transmits this to the home appliance (EE), in step S422 the homeappliance (EE) hands the enciphered commands to the security chip,deciphering is performed at the security chip (SC) (S423), and followinghanding the deciphered commands from the security chip (SC) over (S424),the commands are executed at the home appliance (EE) (S425), theexecution results are transmitted from the home appliance (EE) to theservice provider (SP) as command execution results, and the serviceprovider (SP) which has received the response transmits the nextexecution commands based on the response to the home appliance (EE).

Upon execution of all commands following the maintenance program ending,in step S427 the maintenance program execution processing ends.

The above-described maintenance processing arrangement is an arrangementwherein a service attribute certificate is presented from a user sidehome appliance to a manufacturer side device, while the manufacturerside device presents a control attribute certificate to the homeappliance, verification and screening of the mutual attributecertificates is executed, and services are received or confirmation ofprivileges within a provided range is made.

Usage arrangements for the service attribute certificates and controlattribute certificates are not restricted to the above-describedprocessing arrangements, rather, as shown in FIG. 53 for example, anarrangement may be made wherein both the attribute certificates arestored in a user side device 491 with the service attribute certificate493 and control attribute certificate 494 being presented to themanufacturer side (SP) 492 at the time of requesting services, wherebyverification and screening of the service attribute certificate 493 andcontrol attribute certificate 494 is performed at the manufacturer side(SP) 492, and following confirmation of the relation of the two parties,maintenance processing is preformed with regard to the user side device491 within the range of privileges indicated by the control attributecertificate 494.

Also, an arrangement may be made wherein a program is stored in the homeappliance which periodically automatically performs maintenance atcertain time intervals, with a maintenance request having a serviceattribute certificate being transmitted to the manufacturer side atprogrammed time intervals, and the control attribute certificatetransmission and maintenance processing being carried out by themanufacturer side based on reception of the request.

(5-4) Personal Communication Service

Next, description will be made regarding a communication service usageexample using a PC, PDA, or other like communication terminal serving asan end entity (EE), upon executing privilege confirmation based on agroup attribute certificate.

Here, an example will be described wherein a communication terminalinstalled in the home or the like, which is an end entity (EE) such as aPC, PDA, or other like communication terminal, connects to a server of aservice provider which provides a chat room, so that communicationbetween communication terminals via the chat room, and directcommunication between end entities (EE), is performed as a communicationservice, executing the access restriction processing using groupattribute certificates. An example of the group attribute certificate tobe applied in the communication service is shown in FIG. 54.

The issuer of a group attribute certificate AC01 is a chat administratorserving as the service provider (SP), and the holder, i.e., the holderto which the group attribute certificate AC01 is to be issued byperforming authentication processing with the chat administratingservice provider (SP) at the time of issuing the group attributecertificate AC01, is the security chip (SC) of the end entity which isthe communication terminal of user Mr. A or the user security chip (USC)of the user identification device (UID) of Mr. A.

This group attribute certificate AC01 is an attribute certificateproving access privileges to the server making up the chat room whichthe chat administrating service provider (SP) provides, and is issued toa user group or user device having privileges for participating in thechat room.

The issuer of the group attribute certificate AC02 is a user device (EEor UID) of Mr. B, and the holder, i.e., the holder to which the groupattribute certificate AC02 is issued by performing authenticationprocessing with the security chip (SC) (SC or USC) of the user device ofMr. B which is the issuer at the time of issuing the group attributecertificate AC02, is the security chip (SC or USC) of the user device ofMr. B.

The group attribute certificate AC02 is an attribute certificate provingaccess privileges to the managing service of the user device of Mr. B,and is issued to a user group or user device group having privileges toaccess the managing server of the user device of Mr. B.

Note that the issuing processing of the group attribute certificatesAC01 and AC02 can be performed by the service provider (SP) or the userdevice of Mr. B serving as an end entity (EE) or the user identificationdevice (UID) itself executing functions of a group attribute authority(AA) and group attribute certificate registration authority (ARA), but aconfiguration may also be made wherein issuing processing iscommissioned to a group attribute authority (AA) and group attributecertificate registration authority (ARA). However, processing followingthe policies of the issuer being executed is a condition in this case.

For example, issuing processing of the group attribute certificates AC01and AC02 is preferably performed by the service provider (SP) which isthe issuer, the user device of Mr. B (EE, UID), or a group attributecertificate registration authority (ARA) serving as an issuing agent,causing Mr. A who is an issuance requester, to present an already-issuedgroup attribute certificate which proves the identity of the user, suchas a group attribute certificate issued from a credit card company, andfollowing verification of the presented group attribute certificate, thegroup attribute certificates AC01 and AC02 are issued as new groupattribute certificates. As for conditions for verification of analready-issued group attribute certificate in this way, the processingsequence for issuing the new group attribute certificates is the sameprocessing sequence as that described earlier with reference to FIG. 29,FIG. 30, FIG. 32, and so forth.

The arrangement for issuing and storing group attribute certificatesshown in FIG. 54 is as shown in FIG. 555. The chat room service provider(SP) 501, the communication terminal (EE) 511 of Mr. A serving as an endentity, and the communication terminal (EE) 531 of Mr. B, are capable ofmutually transferring data by a communication network, and thecommunication terminal (EE) 511 and user identification device (UID)521, and communication terminal (EE) 531 and user identification device(UID) 533, capable of mutually transferring data by a communicationnetwork via connected device interfaces 231 (see FIG. 9) of each.

Each of the devices have (user) security chips 512, 522, 532, 534, or asecurity module 502, having anti-tampering configurations, performingmutual authentication processing at the time of data communicationprocessing, and encipherment and decipherment and the like of thetransferred data. Also, verification processing of the group attributecertificate is executed at the security chips and security module.

The user identification device 521 of Mr. A stores the group attributecertificate AC01, 523 described earlier with reference to FIG. 54. Thegroup attribute certificate AC01, 523 has as an issuer the chat roomservice provider (SP) 501, and is applied to chat room participationprivilege confirmation processing, transferred from the USC 521 of theuser device of Mr. A who is the holder, to the chat room serviceprovider (SP) 501, and following verification and screening of the groupattribute certificate AC01 at the security module (SM) of the chat roomservice provider (SP) 501, the service, i.e., participation in the chatroom, is permitted.

Also, the user identification device 521 of Mr. A also stores a groupattribute certificate AC02, 524, as described earlier with reference toFIG. 54. The group attribute certificate AC02, 524 has a the issuer theuser device (EE 531 or UID 533) of Mr. B, and is applied to accessprivilege confirmation processing to the managing server of the userdevice of Mr. B, is transmitted from the USC 521 of the user device ofMr. A who is the holder to the user device (EE 531 or UID 533) of Mr. B,and following verification and screening of the group attributecertificate AC02 at the security chip (SC 532 or USC 534) of the userdevice (EE 531 or UID 533) of Mr. B, service, i.e., access to themanaging server of the device of Mr. B, is permitted.

The processing sequence for applying the group attribute certificateAC01, 523 stored in the user identification device 421 of Mr. A toperform user privilege confirmation processing of chat roomparticipation service, and start the service, will be described withreference to FIG. 56. In FIG. 56,

UID: Mr. A user identification device (user device) control unit,

USC: user security chip configured within the UID,

EE: Mr. A communication device (user device) control unit,

SC: security chip configured within the EE,

SP: chat room service provider (SP) control unit, and

SM: security module within SP.

First, in step S451, a user (Mr. A) inputs a group attribute certificate(Gp. AC)=AC01 usage request command via the input interface of thecommunication terminal (EE) of Mr. A serving as an end entity. Thisgroup attribute certificate (Gp. AC) is the AC01 shown in FIG. 54 andFIG. 55. At this time, the user specifies the group ID set in the groupattribute certificate AC01 to be used. However, in the event that asingle group ID can be determined by specifying a certain service, anarrangement may be made wherein only the service is specified.

Upon the Mr. A communication terminal (EE) receiving the group attributecertificate (Gp. AC) AC01 usage request input from the user, mutualauthentication is performed between the user security chip (USC) and thesecurity module (SM) of the chat room service provider (SP) serving asthe service provider in step S452. Now, while omitted in theillustration here, in the event a user identification device (UID) doesnot have direct communication functions with the SP, all of:

(1) Mutual authentication between the SC of the EE and the SP-SM,

(2) Mutual authentication between the SC of the EE and the USC of theUID, and

(3) Mutual authentication between the USC of the UID and the SP-SM,

is performed. Or as a simpler configuration, a processing configurationmay be made wherein the EE basically accepts (deems authenticated) theUID upon connection to the EE, and in this case, the mutualauthentication (2) above can be omitted. Further, authenticationconfigurations under different combinations of the above three types canbe realized.

The authentication processing is executed as public key mutualauthentication processing described earlier with reference to FIG. 13,centered on the encipherment processing unit (see FIG. 9) of thesecurity chip and security module. In step S453, a mutual authenticationcompletion notification including mutual authenticationestablished/not-established result information is output from the usersecurity chip to the end entity. In the event that the mutualauthentication is not established, continuation of the processing iscancelled. In the event that mutual authentication is established, instep S454 the user security chip (USC) transmits the group attributecertificate (Gp. AC) AC01 stored in its own memory to the securitymodule (SM) of the service provider (SP). The group attributecertificate (Gp. AC) AC01 is the group attribute certificate AC01applied to processing for determining chat room participation receivingright privileges, as described with reference to FIG. 54 and FIG. 55.

In step S455, the security module (SM) of the chat room providingservice provider (SP) which has received the group attribute certificate(Gp. AC) AC01 from the user security chip (USC) executes group attributecertificate verification processing. The verification processing of thegroup attribute certificate is as described earlier with reference toFIG. 21 through FIG. 23, and is executed as processing includingattribute certificate signature verification, corresponding public keycertificate (PKC) and chain public key certificate confirmationprocessing, and so forth.

Following verification processing of the group attribute certificate(Gp. AC), the security module (SM) outputs the verification results tothe chat room providing service provider (SP), and in the event thatverification is not established, providing of services is not executedand the processing is cancelled as error processing. In this case,processing may be performed wherein the end entity is notified to theeffect that verification of the group AC was not established.

In the event that the verification of the group attribute certificate(Gp. AC) is successful and the authenticity of the group attributecertificate (Gp. AC) has been confirmed, the flow proceeds to step S457.In step S457, screening of the group attribute certificate (Gp. AC)described earlier with reference to FIG. 25 is carried out. Thescreening is executed based on the group information database which thechat room providing service provider (SP) serving as the serviceprovider holds. That is to say, the chat room providing service provider(SP) obtains the issuer information and group ID from thealready-verified group attribute certificate (Gp. AC) AC01, searches thegroup information database based on the obtained information, andconfirms whether or not there is a registered entry. In the event thatthere is a corresponding registered entry, the group information isobtained from the group information database.

The group information in this case includes chat room participationpermission information. In step S458, the chat room providing serviceprovider (SP) serving as the service provider performs service providingprocessing, i.e., permits participation to the chat room following thegroup information. That is to say, processing for permitting access tothe server providing the chat room is performed.

Next, the processing sequence for applying the group attributecertificate AC02, 524 stored in the user identification device 421 ofMr. A to perform user privilege confirmation processing to the userdevice of Mr. B, and start communication between MR. A and Mr. B, willbe described with reference to FIG. 57. In FIG. 57,

UID: Mr. A user identification device (user device) control unit,

USC: user security chip configured within the UID,

EE1: Mr. A communication device (user device) control unit,

SC1: security chip configured within EE1,

EE2: Mr. B communication device (user device) control unit, and

SC2: security chip configured within EE2.

First, in step S461, a user (Mr. A) inputs a group attribute certificate(Gp. AC)=AC02 usage request command via the input interface of thecommunication terminal (EE1) of Mr. A serving as an end entity. Thisgroup attribute certificate (Gp. AC) is the AC02 shown in FIG. 54 andFIG. 55. At this time, the user specifies the group ID set in the groupattribute certificate AC02 to be used.

Upon the Mr. A communication terminal (EE1) receiving the groupattribute certificate (Gp. AC) AC02 usage request input from the user,mutual authentication is performed between the user security chip (USC)and the security chip (SC2) of the user device of Mr. B in step S462.Note that the example described here is a case wherein the issuingentity of the group attribute certificate (Gp. AC) AC02 is the securitychip (SC) of the communication terminal (EE) of Mr. B. In a case whereinthe issuing entity is the user identification device (UID) of Mr. B,mutual authentication would be performed with the user security chip(USC) of the user identification device (UID) of Mr. B.

The authentication processing is executed as public key mutualauthentication processing described earlier with reference to FIG. 13,centered on the encipherment processing unit of the security chip andsecurity module. In step S463, a mutual authentication completionnotification including mutual authentication established/not-establishedresult information is output from the user security chip (USC) of Mr. Ato the end entity (EE1). In the event that the mutual authentication isnot established, continuation of the processing is cancelled. In theevent that mutual authentication is established, in step S464 the usersecurity chip (USC) transmits the group attribute certificate (Gp. AC)AC02 stored in its own memory to the security chip (SC2) of thecommunication terminal (EE) of Mr. B. The group attribute certificate(Gp. AC) is the group attribute certificate AC02 applied to processingfor determining access privileges to the server of the user device ofMr. B, as described with reference to FIG. 54 and FIG. 55.

In step S465, the security chip (SC2) of the communication terminal (EE)of Mr. B which has received the group attribute certificate (Gp. AC)AC02 from the user security chip (USC) executes group attributecertificate verification processing. The verification processing of thegroup attribute certificate is as described earlier with reference toFIG. 21 through FIG. 23, and is executed as processing includingattribute certificate signature verification, corresponding public keycertificate (PKC) and chain public key certificate confirmationprocessing, and so forth.

Following verification processing of the group attribute certificate(Gp. AC), the security chip (SC2) of the communication terminal (EE) ofMr. B outputs the verification results to the communication terminal(EE) of Mr. B, and in the event that verification is not established,providing of services is not executed and the processing is cancelled aserror processing. In this case, processing may be performed wherein Mr.A is notified to the effect that verification of the group AC was notestablished.

In the event that the verification of the group attribute certificate(Gp. AC) is successful and the authenticity of the group attributecertificate (Gp. AC) has been confirmed, the flow proceeds to step S467.In step S467, screening of the group attribute certificate (Gp. AC)described earlier with reference to FIG. 25 is carried out. Thescreening is executed based on the group information database which thecommunication terminal (EE) of Mr. B holds. That is to say, thecommunication terminal (EE) of Mr. B obtains the issuer information andgroup ID from the already-verified group attribute certificate (Gp. AC)AC02, searches the group information database based on the obtainedinformation, and confirms whether or not there is a registered entry. Inthe event that there is a corresponding registered entry, the groupinformation is obtained from the group information database.

The group information in this case includes access privilege informationfor access to the server of the communication terminal of Mr. B. In stepS468, the communication terminal (EE) of Mr. B performs serviceproviding processing, i.e., permits access to the server of the userdevice of Mr. B.

[(6) Execution Attribute Certificate (Execution AC)]

Next, an execution attribute certificate (execution AC) which enablesnot only determining service receiving privileges in service providingarrangements based on privilege confirmation using attributecertificates, but also restricting execution of the service itself byattribute certificates, will be described.

(6-1) Execution Attribute Certificate Overview

The above-described group attribute certificates, orconventionally-known general attribute certificates, are capable ofverifying that the stored data of the attribute certificate such asprivilege information or the like which is a holder attribute, has notbeen tampered with, by signature verification. The execution attributecertificate (execution AC) which will be described below not onlyexecutes confirmation that the certificate has not been tampered with,by verification, but also has a configuration for deciphering enciphereddata (program) stored the execution attribute certificate by thecertificate holder, and receiving services based on the deciphering ofthe enciphered data (program).

A key (registered key) applied for deciphering enciphered data (program)stored in an execution attribute certificate is a secret shared keywhich only the issuer of the execution attribute certificate and theholder of the execution attribute certificate which is the security chip(SC) of the user device corresponding to the service receiver, can know.Accordingly, execution of services based on the execution attributecertificate can be made only with predetermined user devices.

Note that in the following, description will be made regarding anarrangement wherein the security chip (SC) of the user device which isthe end entity (EE) executes processing of the execution attributecertificate, but the processing of the security chip (SC) describedbelow is processing which can be carried out in the same way by the usersecurity chip (USC) of the user identification device (UID), as with theprocessing of the group attribute certificate described above.

As shown in FIG. 58(a), the execution attribute certificate has datawhich is an execution command such as a program or the like necessaryfor executing the provided service that has been enciphered with aregistration key, and a memory region block address which is addressdata indicating a registration key storage region in memory of thesecurity chip storing the registration key, e.g., the registration keystorage region in the shared key memory region 207 formed within theEEPROM 206 of the security chip shown in FIG. 58(c) for example.Further, the execution attribute certificate has various types ofattribute certificate data (see FIG. 5), with the signature of theissuer affixed. Data tampering verification can be executed by signatureverification. Signature generating and verification processing can beexecuted following the processing described earlier with reference toFIG. 17 and FIG. 18.

Also note that the execution attribute certificate can be configuredcompliant to the basic format of attribute certificates, compliant withITU-T X.509 for example. However, following the format stipulated byITU-T X.509 is not indispensable, and an original format may be used toconfigure the attribute certificate.

As shown in FIG. 58(b), the shared key memory region 207 of the securitychip (SC) has stored multiple registration keys corresponding tomultiple execution attribute certificates which an end entity (EE)serving as a user device holds, corresponding to predetermined blockaddresses.

The shared key memory region 207 is a memory region in non-volatilememory made up of blocks of a fixed size, such as 64 bits for example.Storage processing and resetting processing of registration keys iscarried out following predetermined procedures. This processing will bedescribed later. Except for reset commands, access to the registrationkey storage memory region can only be realized by using a commandenciphered with the registration key stored in the block to be accessed.Also, with regarding secret keys as well, in addition to an arrangementwherein secret keys cannot be read out, and arrangement is conceivedwherein enciphered or deciphered results cannot be directly read outwith the secret key. Here, the term cannot be directly read out meansthat enciphering with the secret key following applying a hash function,or deciphering and executing command enciphered with a public key, canbe realized. In the following a security chip or a module which is theholder of an execution attribute certificate is to be understood to havesuch an arrangement.

An overview of the usage procedures of an execution attributecertificate will be described following the flowchart in FIG. 59. FIG.59 illustrates a flowchart schematically showing the processing at aservice provider (SP) serving as an issuer of the execution attributecertificate, and a user device serving as a receiver of a servicethrough the execution attribute certificate, for example. In step S501,mutual authentication is executed between the service provider (SP) andthe user device, and in step S502, screening of service usage privilegesbased on a group attribute certificate as described above for example,is performed. The processing here is the same as the authenticationprocessing and verification processing with group attribute certificatesdescribed above, and the authentication processing is executed as publickey mutual authentication processing described earlier with reference toFIG. 13, centered on the encipherment processing unit of the securitychip and security module (see FIG. 9). The verification processing is asdescribed earlier with reference to FIG. 21 through FIG. 23, and isexecuted as processing including attribute certificate signatureverification, corresponding public key certificate (PKC) and chainpublic key certificate confirmation processing, and so forth.

Next, as processing in step S503, service providing processing based onthe execution attribute certificate (execution AC) is performed. Serviceproviding processing based on the execution attribute certificate(execution AC) is carried out by one of: the execution attributecertificate (execution AC) issuing processing shown in step S504; theexecution attribute certificate (execution AC) applying processing shownin step S505; and the execution attribute certificate (execution AC)destroying processing shown in step S506.

(6-2) Execution Attribute Certificate Issuing Processing

First, execution attribute certificate issuing processing will bedescribed. FIG. 60 illustrates the issuing sequence of an executionattribute certificate. In FIG. 60,

EE: user device end entity (EE) control unit,

SC: security chip configured within the EE,

Execution AC table: execution AC managing table storage memory andmemory control unit

SP: service provider device for executing execution AC issuingprocessing (SP) control unit, and

SM: security module within SP.

First, in step S511, a user inputs an issuing request command for aexecution attribute certificate (execution AC) via the input interfaceof the end entity (EE) serving as a user device. Upon the end entity(EE) receiving the execution attribute certificate issuing request inputfrom the user, mutual authentication is performed between the securitychip (SC) and the security module (SM) of the service provider (SP) instep S512, as well as verification and screening of an already-issuedgroup attribute certificate applied to the issuing conditions for anexecution attribute certificate (execution AC).

The authentication processing is executed as public key mutualauthentication processing described earlier with reference to FIG. 13,centered on the encipherment processing unit of the security chip andsecurity module (see FIG. 9). The verification processing is asdescribed earlier with reference to FIG. 21 through FIG. 23, and isexecuted as processing including attribute certificate signatureverification, corresponding public key certificate (PKC) and chainpublic key certificate confirmation processing, and so forth.

Note that while the description here is of an example of issuingprocessing of an execution attribute certificate to the security chip(SC) of an end entity (EE), in the event of issuing an executionattribute certificate to the user security chip (USC) of the useridentification device (UID), all of:

(1) Mutual authentication between the SC of the EE and the SP-SM,

(2) Mutual authentication between the SC of the EE and the USC of theUID, and

(3) Mutual authentication between the USC of the UID and the SP-SM,

is performed. Or as a simpler configuration, a processing configurationmay be made wherein the EE basically accepts (deems authenticated) theUID upon connection to the EE, and in this case, the mutualauthentication (2) above can be omitted. Further, authenticationconfigurations under different combinations of the above three types canbe realized.

Upon the authentication, group attribute certificate verification andscreening, in step S512 being all established, the service provider (SP)performs registration key generating execution AC generating informationrequest processing to the end entity (EE) of the user device.Specifically, this is processing for requesting an available memoryregion address in the memory to be used as the storage region for theregistration key to be applied to encipherment and deciphermentprocessing of the execution command (FIG. 58) of the execution attributecertificate.

Upon the end entity (EE) receiving the registration key generatingexecution AC generating information request, in step S514, an availablememory region address search for memory to be used for the storingregion of the registration key is output to an execution AC tablecontrol unit, and the execution AC table (control unit) responds to thisrequest by making reference to the execution AC table and notifying theend entity of an available memory region address to be used to store anewly-registered registration key. As shown in FIG. 62 for example, anExecution AC table is a table correlating SP information which isidentification data of a service provider, service information which theservice provider provides, such as enciphered content information forexample, and an execution AC stored as execution commands of a programnecessary to use the service information provided by the serviceprovider. The execution AC table is stored in memory within the endentity (EE) or the security chip (SC).

The execution AC table (control unit) makes reference to memory regionblock addresses of registration keys corresponding to execution ACsalready stored, detects an available address in its own security chip,and notifies the end entity of the available memory region address wherethe new-registration registration key should be stored. The execution ACtable control unit is a control unit which performs access control ofthe memory storing the execution AC table, and is made up of a CPU orthe like executing data extraction, and for executing memory accesscontrol processing for end entities (EE) or security chips (SC).

In step S516, the end entity (EE), transmits the available address tothe service provider (SP). The service provider (SP) which has receivedthe new-registration key memory region block address outputs agenerating request for a registration key generating execution AC to thesecurity module (SM) in step S517. In step S518, the security module(SM) performs generating processing for the registration key generatingexecution AC. The registration key generating execution AC generatingrequest output from the service provider (SP) to the security module(SM) includes a security chip public key certificate storing a securitychip public key (KpSC), a reset key (Kreset) used for resetting theregistration key, a registration key generating command (GenKer), and amemory region block address (Ad).

The details of the generating processing for the registration keygenerating execution AC at the security module (SM) will be describedwith reference to FIG. 63.

The security module (SM) 601 has the same configuration as that of thesecurity chip configuration described earlier with reference to FIG. 9,with FIG. 63 illustrating the extracted encipherment processing unit andmemory unit thereof. The encipherment processing unit comprises a publickey encipherment engine 602, and shared key encipherment engine 603. Thesecurity module (SM) 601 has a configuration such as of a CPU, RAM, ROM,etc., as described earlier with reference to FIG. 9, and is capable alsoof data processing, and data input/output processing.

The public key encipherment engine 602 executes pubic key encryptionsuch as elliptic curve encryption, or RSA (Rivest-Shamir-Adleman)encryption, and performs processing such as data encipherment anddecipherment, signature generation, verification processing, and soforth. The shared key encipherment engine 603 executes shared keyencipherment processing such as, for example, DES, triple DES, and soforth, and performs data encipherment and decipherment and so forth. Thesecurity module (SM) 601 further has hash generating processing, andrandom number generating processing functions.

At the time of a registration key generating execution AC generatingrequest such as described above, the security module (SM) inputs thesecurity chip public key certificate storing the security chip publickey (KpSC), the rest key used for resetting the registration key(Kreset), the registration key generating command (GenKer), and memoryregion block address (Ad).

In the random number generating processing in step S541, the session key(Kcs) based on the generated random number, and the registration keygenerating command (GenKer) are enciphered using the security chippublic key (KpSC) inn step S542, thereby generating enciphered data(Ep(GenKcr∥Kcs;KpSC). Note that a∥b indicates linked data, and Ep(a;b)indicates an enciphered message based on the public key encipheringmethod of a, applying a key b.

Next, in step S543, execution command adding processing is performed.Dpc[a] indicates an execution command for executing a command within thedata a based on decipherment with the secret key based on the public keyenciphering method. Further, in step S544, shared key enciphermentprocessing based on the reset key (Kreset) is executed, therebygenerating the enciphered data (Ec(Dpc[Ep(GenKcr|∥Kcs;KpSC)];Kreset).Ec(a;b) indicates an enciphered message based on the shared keyenciphering method of a, applying a key b.

Further, in step S545, linked data of the enciphered data(Ec(Dpc[Ep(GenKcrl|∥Kcs;KpSC)];Kreset) and the memory region blockaddress (Ad) indicating the storage region of the new-registration keyis subjected to signature processing applying the secret key (KsSM) ofthe security module (SM). As a result of these processes, a registrationkey generating execution AC 611 is generated.

The registration key generating execution AC 611 is of a configurationincluding the

memory region block address (Ad) indicating the storage region of thenew-registration key,

enciphered data (Ec(Dpc[Ep(GenKcr|∥Kcs;KpSC)];Kreset), and

signature data Ep(H(Ad∥Ec(Dpc[Ep(GenKcr|∥Kcs;KpSC)];Kreset;KsSM). Notethat H(a) indicates the hash value of a.

Description will be continued, returning to the sequence diagram in FIG.60. In step S518, upon the registration key generating execution ACgenerating processing at the security module (SM) ending, theregistration key generating execution AC is sent from the securitymodule (SM) to the service provider (SP), and in step S519, theregistration key generating execution AC is sent from the serviceprovider (SP) to the end entity (EE) of the user device.

In step S520, the end entity (EE) of the user device transmits an updaterequest to the execution AC table (see FIG. 62) of the execution ACtable (control unit), where the execution AC table (control unit)updates the execution AC table in step S521. The update request for theexecution AC table (see FIG. 62) includes content information which canbe used by applying the newly-registered key, service providerinformation, and memory region block address, and this information isregistered as new entries to the execution AC table.

Further, the end entity (EE) of the user device outputs a registrationkey generating request to the security chip (SC) in step S522. Thisrequest is performed as processing wherein the registration keygenerating execution AC is sent to the security chip (SC).

The security chip (SC) executes the registration key generatingprocessing in step S523. Description will be made regarding theregistration key generating processing based on the registration keygenerating execution AC executed at the security chip with reference toFIG. 64.

The security chip (SC) 605 is of the same configuration as the securitychip configuration described with reference to FIG. 9 earlier. However,this comprises a shared key memory region, as described with referenceto FIG. 58. FIG. 64 illustrates the enciphering processing unit andmemory unit of the configuration there in an extracted manner. Theencipherment processing unit comprises a public key encipherment engine606, and shared key encipherment engine 607, and has a shared key memoryregion 608 for the memory unit thereof. The security chip (SC) 605 has aconfiguration such as of a CPU, RAM, ROM, etc., as described earlierwith reference to FIG. 9, and is capable also of data processing, suchas data processing based on execution commands enciphered at theenciphering processing unit for example, and data input/outputprocessing. For example, writing and reading data to and from the sharedkey memory 608, external data input, external data output, data transferbetween devices, and like data processing, is executed based on thecontrol of the CPU.

The public key encipherment engine 606 executes pubic key encryptionsuch as elliptic curve encryption, or RSA (Rivest-Shamir-Adleman)encryption, and performs processing such as data encipherment anddecipherment, signature generation, verification processing, and soforth. The shared key encipherment engine 607 executes shared keyencipherment processing such as, for example, DES, triple DES, and soforth, and performs data encipherment and decipherment and so forth. Theshared key memory region 608 is memory storing registration keys, and ismemory formed of non-volatile memory made up of fixed-sized blocks suchas 64 bits for example. The security chip (SC) 605 further has hashgenerating processing, and random number generating processingfunctions.

The security chip (SC) inputs the registration key generating AC 611from the end entity at the time of the registration key generatingrequest.

In step S551, the execution command data (Dpc[Ec(GenKcr∥Kcs;KpSC)] ofthe registration key generating AC 611 is extracted by shared keydeciphering applying the reset key (Kreset), and further, in step S552,as data processing corresponding to the deciphered execution command,the linked data of the registration key generating command (GenKer) andsession key (Kcs) by public key deciphering applying the secret key(KsSC) of the security chip.

The next step S553 is also data processing corresponding to adeciphering execution command, and is an execution processing step forregistration key generating processing (GenKer). In step S554, aregistration key (Ker) based on a random number is generated, and instep S555, a registration key (Kcr) is written to the shared key memoryregion 608 following the memory region block address (Ad) which is thestorage region address of the registration key.

Further, in step S556, the linked data of the registration key (Kcr) andmemory region block address (Ad) is enciphered with the session key(Kcs), and output to the end entity (EE) as the registration keygenerating results 612.

The output step of the registration key generating results 612 to theend entity (EE) is equivalent to the step S524 in FIG. 61.

The registration key generating results obtained by the linked data ofthe registration key (Kcr) and memory region block address (Ad) beingenciphered with the session key (Kcs) is transmitted from the end entity(EE) of the user device to the service provider (SP).

Upon receiving the registration key generating results, the serviceprovider (SP) transmits the registration key generating results to thesecurity module (SM) in step S526, thereby making a request to generatea service providing execution AC. The security module (SM) executes theservice providing execution AC generating processing in step S527.

The service providing execution AC generating processing by the securitymodule (SM) will be described with reference to FIG. 65.

First, in step S561, the session key (Kcs) is applied to executedeciphering processing of the registration key generating results, andobtain the linked data (Ad∥Kcr) of the registration key (Kcr) and thememory region block address (Ad). Further, in step S562, an executioncommand (DecEData∥Kcd) 613 for storing to the service providingexecution AC is enciphered applying the registration key (Kcr). Notethat an execution command is an execution command for an executionprogram or the like, set according to the service providing executionAC. Here, an example is illustrated of an execution command configuredof linked data of a data deciphering key (Kcd) and enciphered datadeciphering command (DecEData).

Further, in step S563, a secret key (KsSM) of the security module isused to generate a signature (see FIG. 17) with regard to the enciphereddata (Ec(DecEData∥Kcd);Kcr) wherein the execution command (DecEData∥Kcd)613 has been enciphered with the registration key (Kcr), and the data ofthe memory region block address (Ad) of the security chip of the userdevice storing the registration key (Ker), thereby generating a serviceproviding execution AC 614. Here, the service providing execution AC 614is an execution attribute certificate for executing the enciphermentprocessing of enciphered data as a service.

Application of the registration key (Kcr) is indispensable fordeciphering the executing command stored in the execution attributecertificate, and the only one that has the registration key informationhere is the security chip (SC) of the user device participating in theservice providing execution AC generating processing, and the securitymodule (SM) of the service provider.

Returning to FIG. 61, description will be continued of the sequencediagram. Upon the security module (SM) generating the service providingexecution AC in step S527, this is sent from the privilege serviceprovider (SP) to the end entity (EE) of the user device in step S528,and further in step S529, is sent to the execution AC table controlunit, and in step S530, is stored in the execution AC table (see FIG.62).

Due to the above processing, as shown in FIG. 58(a), the memory regionblock address of the security chip of the user device storing theregistration key, the execution command enciphered with the registrationkey, and further the issuer signature, and execution attributecertificate (execution AC) having the above data, are stored in the userdevice. Note that besides these data, data of the fields of the groupattribute certificate described earlier with reference to FIG. 5 mayalso be optionally stored. However, the signature must be executed forall data which is the object of tampering checking.

(6-3) Execution Attribute Certificate Application Processing

Now, the application processing of the execution attribute certificateissued by the above-described procedures will be described. FIG. 66 isan application sequence at the user device side of the service providingexecution AC. The service providing execution AC has already been storedin the execution AC table of the user device by the above-describedprocessing.

In step S571, the user inputs a service providing execution ACapplication processing request through the user interface of the endentity (EE). This processing request includes execution AC identifier,or service provider (SP) information, data whereby service contents canbe identified, such as usage content or usage program specified data.The end entity (EE) outputs a search request for the service providingAC which the user has specified to the execution AC table in step S572.The search key is, for example, content information, service provider(SP) information, or the like.

In step S573, the execution AC table searches the corresponding serviceproviding execution ACs based on the input key from the end entity, andoutputs the service providing execution AC extracted form the table tothe end entity (EE) in step S574.

In step S575, the end entity (EE) outputs the received AC to thesecurity chip (SC), and makes a service providing execution ACapplication processing request. In step S576, the security chip performsproviding processing for the received AC, i.e., service providingfollowing the execution attribute certificate (execution AC).

The details of the service providing processing in step S576 at thesecurity chip (SC) will be described with reference to FIG. 67. Thesecurity chip 605 inputs the service providing execution AC 614.

The service providing execution AC 614 includes the(Ec(DecEData∥Kcd);Kcr) data wherein the execution command (DecEData∥Kcd)has been enciphered with the registration key (Kcr), the memory regionblock address (Ad) in the security chip of the user device storing theregistration key (Kcr), and data whereby each data has been signed bythe secret key (KsSM) of the security module.

In step S581, The security chip 605 obtains the registration key (Kcr)from the shared key memory region 608 following the memory region blockaddress (Ad) within the service providing execution AC, executesdeciphering processing of the enciphered data (Ec(DecEData∥Kcd);Kcr)within the service providing execution AC using the obtainedregistration key (Kcr), thereby obtaining the data deciphering key (Kcd)and deciphered command (DecEData) of the enciphered data.

In step S582, data processing based on the deciphered execution commandis executed. That is to say, the data deciphering key (Kcd) is appliedto executing deciphering processing of the enciphered data(Ec(data;Kcd)) 615 to be deciphered which is externally input, therebyoutputting deciphered data 616. This enciphered data (Ec(data;Kcd)) 615to be deciphered is data such as images, music, programs, and likecontents, enciphered with the key (Kcd), and can be deciphered by thedata deciphering key (Kcd) which is obtained by deciphering the storageexecuting command with the registration key (Kcr) within the serviceproviding execution AC.

Description will continue, returning to the sequence diagram in FIG. 66.Following providing the service in step S576, in step S577 the securitychip (SC) performs registration key destruction processing. Thisregistration key destruction processing is executed according to heservice providing execution AC in some cases and is unnecessary toexecute in other cases. In the case of an execution AC wherein theservice providing processing based on the service providing execution ACis only once, this destruction processing is executed following theservice providing processing.

The SC (security chip) registration key destruction process in step S577will be described with reference to FIG. 68. The registration key resetprocessing is performed by overwriting the reset key (Kreset) in thestored region of the registration key in the shared key memory region608. In the event that a reset processing command 617 made up of thememory region block address (Ad) of the registration key (Kcr) to bedestroyed and the reset key (Kreset) is input from an end entity (EE)for example, in step S583 writing processing of the reset key (Kreset)is executed at the memory region corresponding to the memory regionblock address (Ad) stored in the reset processing command 617, and thusdeletion of the registration key is completed.

Description will continue, returning to the sequence diagram in FIG. 66.In step S577, upon destruction of the registration key being completed,a registration key destruction notification is output to the end entity(EE) in step S578, and in step S579 the end entity (EE) outputs aservice providing execution AC deletion request to the execution ACtable, and the execution AC table (control unit) deletes thecorresponding execution AC from the execution AC table.

(6-4) Registration Key Resetting Processing

Note that the registration key destruction processing may not beperformed following the providing processing of the service providingexecution AC, and the reset processing which is the registration keydestruction processing may be executed based on a reset request at anarbitrary timing. Description will be made regarding the processingbased on this reset request, with reference to FIG. 69.

In step S601, a user inputs a registration key reset requestcorresponding to a service providing execution AC stored in the userdevice, via the user interface of an end entity (EE). In step S602, theend entity (EE) outputs a search request to the execution AC table.There are two arrangement for reset requests. One arrangement is for acase wherein the user forgets the service contents written to a certainmemory region block address of the execution AC table, in which theexecution AC table is searched with the memory region block address as akey, and in the event that determination is made that the registrationkey corresponding to the output SP information/contents information isunnecessary, a reset execution request is made. This processing requestincludes an execution AC identifier, or data for specifying the servicecontents such as, for example, contents, program, or service provider(SP) information data. The second arrangement is for a case wherein theuser knows the SP information and content information, and the executionAC table is searched with this as a key, and the output memory regionblock address is transmitted to the SC along with a reset executionrequest/Note that the memory region block address of the registrationkey can be arbitrarily stored in the contents or in the end entity asdata corresponding to the service provider.

In step S603, the execution AC table searches the corresponding serviceproviding execution AC based on the input key from the end entity, andsearches the service providers corresponding to the service providingexecution AC and usable contents, which are output to the end entity(EE) in step S604.

The end entity (EE) displays the service provider and usable contentsinformation, and if determined to be unnecessary, a reset executionrequest is output to the security chip in step S606.

The registration key reset processing is performed by overwriting thestorage region of the registration key in the shared key memory regionwith the reset key (Kreset), a reset processing command made up of thememory region block address (Ad) of the registration key (Kcr) to bedestroyed and the reset key (Kreset) is input from the end entity (EE),and in step S607, writing processing of the reset key (Kreset) isexecuted at the memory region corresponding to the memory region blockaddress (Ad) as describe earlier with reference to FIG. 68, whereby theregistration key is reset. Upon resetting of the registration key beingcompleted in step S607, a reset completed notification is output to theend entity (EE) in step S608.

(6-5) Execution Attribute Certificate Reset (Destruction) Processing

Next, execution attribute certificate reset (destruction) processingwherein an execution attribute certificate stored in the user device isdestroyed, and the fact that destruction has been executed without failis notified to the service provider, will be described.

Description will be made following the processing sequence in FIG. 70and FIG. 71. In FIG. 70 and FIG. 71,

EE: user device end entity (EE) control unit,

SC: security chip configured within the EE,

Execution AC table: execution AC managing table storage memory andmemory control unit

SP: service provider device control unit (SP) for executing execution ACissuing processing, and

SM: security module within SP.

First, in step S611, a user inputs an execution attribute certificate(execution AC) destruction application request command via the inputinterface of the end entity (EE). Based on this request, the executionattribute certificate destruction application is transmitted to theservice provider. The application includes for example, executionattribute certificate (execution AC) ID, or contents and servicespecifying data or the like, capable of identifying the executionattribute certificate (execution AC) to be destroyed.

Upon the service provider device control unit (SP) receiving theexecution attribute certificate destruction application, in step S612,mutual authentication between the security chip (SC) and security module(SM) of the service provider (SP) is performed, and if necessary,verification and screening processing of an already-issued groupattribute certificate issued to the service provider to be applied asthe execution attribute certificate (execution AC) destructionconditions, is performed. Viewing the execution attribute certificatedestruction processing as a service, the end entity acts as the serviceprovider.

The authentication processing is executed as public key mutualauthentication processing described earlier with reference to FIG. 13,centered on the encipherment processing unit of the security chip andsecurity module (see FIG. 9). The verification processing is asdescribed earlier with reference to FIG. 21 through FIG. 23, and isexecuted as processing including attribute certificate signatureverification, corresponding public key certificate (PKC) and chainpublic key certificate confirmation processing, and so forth.

Note that while the description here is of an example of destroyingprocessing of an execution attribute certificate to the security chip(SC) of an end entity (EE), in the event of destroying an executionattribute certificate of the user security chip (USC) of the useridentification device (UID), all of:

(1) Mutual authentication between the SC of the EE and the SP-SM,

(2) Mutual authentication between the SC of the EE and the USC of theUID, and

(3) Mutual authentication between the USC of the UID and the SP-SM,

is performed. Or as a simpler configuration, a processing configurationmay be made wherein the EE basically accepts (deems authenticated) theUID upon connection to the EE, and in this case, the mutualauthentication (2) above can be omitted. Further, authenticationconfigurations under different combinations of the above three types canbe realized.

Upon the authentication, group attribute certificate verification andscreening, in step S612 being all established, the end entity of theuser device makes a search request for the execution AC to be destroyed,to the execution AC table in step S613. The search key is, for example,contents information or service provider (SP) information or the like.

In step S614, the execution AC table searches the corresponding serviceproviding execution AC based on the input key from the end entity, andin step S615 outputs the service providing execution AC extracted fromthe table to the end entity (EE). Further, the execution AC table(control unit) deletes the entry of the execution AC to be destroyedfrom the execution AC table in step S616.

In step S617, the end entity (EE), outputs a resent execution request tothe security chip. In step S618, processing for overwriting the resetkey (Kreset) in the storage region of the registration key in the sharedkey memory region is performed as registration key resetting processing(see FIG. 68), and a reset completed notification is output to the endentity (EE).

Further, the end entity (EE) transmits the reset completed notificationto the service provider (SP) in step S621 indicated in FIG. 71. Thisreset completed notification has with it the execution AC to bedestroyed. The service provider (SP) which has received the execution ACto be destroyed outputs a generating request for a reset conformationexecution AC in step S622 to the security module (SM). This request isexecuted along with the execution AC to be destroyed.

In step S623, the security module (SM) extracts the memory region blockaddress information storing the corresponding registration key from theexecution AC to be destroyed, and in step S624 executes resetconfirmation execution AC generating processing. The reset confirmationexecution AC is a data configuration including the memory region blockaddress information (Ad) storing the corresponding registration key ofthe execution AC to be destroyed, an execution command which is acommand to be executed at the security chip (SC) of the user device bythe reset confirmation execution AC, and a signature of the issuer,i.e., the security module (SM) (see the reset confirmation execution AC621 in FIG. 72).

The generated reset confirmation execution AC is transmitted from theservice provider (SP) to the end entity (EE) in step S625, and furtherin step S626 is transferred to the security chip (SC).

At the security chip (SC), in step S627, reset confirmation resultgenerating processing based on the reset confirmation execution AC isperformed. The details of the reset confirmation generating processingof step S627 will be described in detail with reference to FIG. 72.

As shown in FIG. 72, in step S641 the security chip 605 deciphers theexecution command of the reset confirmation execution AC, applying thereset key (Kreset) extracted from the shared key memory region 608 basedon the address stored in the reset confirmation execution AC 621,obtains the deciphered command data (Dpc[Ep(ConfReset∥Kcs;KpSC)] of thedata (Ep(ConfReset∥Kcs;KpSC)) enciphered with the public key (KpSC) ofthe security chip, and in step S642 deciphers with the secret key of thesecurity chip (KsCS), obtains the reset information result generatingcommand (ConfReset) and session key (Kcs), and executes the resetconfirmation result generating processing of step S643.

With the reset confirmation result generating processing in step S643,first, in step S644, the reset key (Kreset) is read out from the sharedmemory region 608 based on the address stored in the reset confirmationexecution AC 621, and further, in step S645, linked data of the memoryregion block address information (Ad) and the reset key (Kreset) isenciphered with the session key (Kcs), and a reset confirmation result622 formed of enciphered data (Ec(Ad∥Kreset;Ksc)) is output to the endentity (EE).

The end entity (EE) transmits the reset confirmation result to theservice provider (SP) in step S628 in FIG. 71, the service provider (SP)transmits the reset confirmation result to the security module (SM) instep S629, and the security module (SM) transmits the reset confirmationresult to the service provider (SP), whereby the processing ends.

With the processing described above, destroying processing of an issuedexecution AC is carried out in a sure manner under the service provider.

Note that the registration key destruction processing can be performedbased on an execution AC. Registration key destruction processingperformed based on an execution AC will be described with reference toFIG. 73. A registration key execution AC is issued by the serviceprovider (SP) which has issued the corresponding service providingexecution AC for example, and is input to the security chip (SC) via theend entity (EE) of the user device.

The registration key destroying execution AC 623 is an AC having thememory region block address information (Ad) of the shared key memoryregion storing a registration key to be destroyed, a registration keydestruction command (RevK) enciphered with the registration key, and anissuer signature, as shown in FIG. 73.

In step S651, the execution command of the registration key destroyingexecution AC 623 is deciphered based on the registration key (Kcr)obtained from the shared key memory region 608, based on the memoryregion block address information (Ad) of the registration key destroyingexecution AC 623, a destruction command (RevK) is obtained, anddestruction processing is executed based on the command in step S652. Instep S653, the reset key (Kreset) is overwritten in the correspondingmemory region based on the memory region block address information (Ad)of the registration key destroying execution AC 623, whereby theregistration key is destroyed (reset).

[(7) Specific Usage-Processing of Execution Attribute Certificate]

Next, specific processing applying the above-described executionattribute certificate (execution AC) will be described. As examples ofthe usage processing, the following items will each be described.

(7-1) Service providing execution attribute certificate withrestrictions on the number of times

(7-2) Service providing execution attribute certificate with transferfunction

(7-3) Proxy execution attribute certificate

(7-1) Service Providing Execution Attribute Certificate withRestrictions on the Number of Times

First, description will be made regarding the application processing ofa service providing execution attribute certificate with restrictions onthe number of times. FIG. 74 and FIG. 75 illiterate a processingsequence for applying the service providing execution attributecertificate with restrictions on the number of times to decipher and useenciphered data with restrictions on the number of times, such as imagesmusic, programs, and like contents. Description will be made of theprocessing sequence following the steps.

Let us say that a user device already has a service providing executionattribute certificate with restrictions on the number of times stored inmemory, e.g., the aforementioned execution AC table, with the number oftimes remaining for use being n times. Number or remaining usage timesdata (e.g., n times) is recorded in the execution command of the serviceproviding execution attribute certificate with restrictions on thenumber of times as an applicable number of times identification value.An example of recording will be described later.

In step S701, the user inputs a service providing execution AC via theuser interface of the end entity (EE), in this case, an applicationprocessing request for an enciphered data deciphering execution AC. Thisprocessing request contains an execution AC identifier, or serviceprovider (SP) information, data identifying service contents, forexample usage contents specifying data. In step S702, the end entity(EE) outputs the search request for the user-specified service providingexecution AC (enciphered data deciphering execution AC) to the executionAC table. The search key is, for example, contents information orservice provider (SP) information or the like.

In step S703, the execution AC table searches for the correspondingenciphered data deciphering execution AC based on the input key from theend entity, and in step S704, outputs the enciphered data decipheringexecution AC extracted from the table, to the end entity (EE). Thenumber of remaining times=n times information is recorded in thisenciphered data deciphering execution AC.

In step S704, the end entity (EE) outputs the received AC to thesecurity chip (SC) and makes an application processing request for theservice providing execution AC (enciphered data deciphering executionAC). This application processing is performed as follows. First, in stepS705, deciphering key setting processing is executed by deciphering theexecution command of the enciphered data deciphering execution AC withthe registration key, a deciphering key setting completed notificationis output to the end entity (EE) (S706), and at the EE, enciphered datato be deciphered is obtained from external memory for example (S707), adeciphering request is made to the SC (S708), data decipheringprocessing is executed at the SC (S709), data deciphering processing fortransmitting the deciphered data from the SD to the EE is performed(S710), and further, in step S711, the remaining number of usage timesdata within the execution command of the enciphered data decipheringexecution AC is updated from n to n−1.

Further, following determining the remaining number of usage times afterupdating (S712), in the event that the remaining number of usagetimes≧1, the sequence shown in FIG. 75(a) is followed so thatre-generation of the registration key and saving thereof (S721),re-generating of the enciphered data deciphering execution AC (S722),transmission to the EE, and saving to the execution AC table (S724) inresponse to an enciphered data deciphering execution AC saving requestfrom the EE (S723), are performed.

On the other hand, in the event that the remaining number of usagetimes=0, the sequence shown in FIG. 75(b) is followed so thatregistration key destruction processing (S725) is executed at the SC,and following a registration key destruction notification to the EE(S726), enciphered data deciphering execution AC deletion (S728) isexecuted for the execution AC table, according to an enciphered datadeciphering execution AC deletion request (S727) from the EE.

The processing at the security chip (SC) from step S705 on will bedescribed with reference to FIG. 76 and FIG. 77. FIG. 76 is theprocessing carried out in the event that the remaining number of usagetimes≧1, and FIG. 77 is the processing carried out in the event that theremaining number of usage times=0.

First, with reference to FIG. 76, processing at the security chip (SC)in the event that the remaining number of usage times≧1 will bedescribed.

A service providing execution attribute certificate with restrictions onthe number of times 701 includes an execution command(Ec(DecEData∥Kcd∥NumTr(n);Kcr1)), a block address (Ad) in the shared keymemory region storing the registering key for enciphering the executioncommand, and an issuer signature. The execution command contains anenciphered data deciphering command (DecEData), data deciphering key(Kcd), and a number-of-times processing execution command (NumTr(n))corresponding to the remaining number of usage times (n), and is anexecution command (Ec(DecEData∥Kcd∥NumTr(n);Kcr1)) wherein these dataare enciphered by the registration key (Kcr1).

First, the security chip (SC) deciphers the execution command of theexecution AC 701 applying the registration key (Kcr1) extracted from theshared key memory region based on the block address (Ad) in theexecution AC in step S731, extracts the data (DecEData∥Kcd∥NumTr(n)),and further applies the data deciphering key (Kcd) in step S732, so asto execute deciphering of enciphered data 702 (Ec(Data;Kcd)) such asexternally-input enciphered contents or the like, and the decipheredcontents (data) are output to the end entity.

Further, in step S733, processing is executed based on a number of timesprocessing command (NumTr(n)). This processing is processing of whichthe object is to generate a new service providing execution attributecertificate with restrictions on the number of times 704 by updating theremaining number of usage times.

A new registration key Kcr2 is generated by random number generatingprocessing (S734), and is written to the shared memory region 608corresponding to the block address to which the original serviceproviding execution attribute certificate with restrictions on thenumber of times 701 was written. Accordingly, the registration key(Kcr1) written thereto before is replaced with the new registration key(Kcr2).

In step S736, the remaining number of usage times=n extracted based onthe number of times processing command (NumTr(n)) is subjected toupdating of being decremented by 1, upon the contents decipheringprocessing being performed. This rewrites the data(DecEData∥Kcd∥NumTr(n)) in the execution command to(DecEData∥Kcd∥NumTr(n−1)), and in step S737, deciphering processingusing the newly-generated registration key (Kcr2) is executed. Theencipherment data is equivalent to the execution command(Ec(DecEData∥Kcd∥NumTr(n−1);Kcr2)) within the new service providingexecution attribute certificate with restrictions on the number of times704.

In step S738, the block address (Ad) and an electronic signature basedon the execution command having the updated remaining number of usagetimes generated in step S737 are executed by the secret key (KsSC) ofthe security chip, and a new and updated service providing executionattribute certificate with restrictions on the number of times 704 isnewly generated. The signature in this case is performed at the securitychip.

The new and updated service providing execution attribute certificatewith restrictions on the number of times 704 newly generated is outputfrom the security chip (SC) to the end entity (EE) in step S722 in FIG.75, and then is saved in the execution AC table in step S724.

On the other hand, processing at the security chip (SC) in the eventthat determination has been made that the remaining number of usagetimes=0 for the remaining number of usage times inspection in theprocessing step 712 in FIG. 74 will be described with reference to FIG.77.

The service providing execution attribute certificate with restrictionson the number of times 705 has an execution command(Ec(DecEData∥Kcd∥NumTr(1);Kcr1)), block address (Ad of the shared keymemory region storing the registration key for deciphering the executioncommand, and an issuer signature.

First, the security chip (SC) deciphers the execution command of theexecution AC 705 applying the registration key (Kcr1) extracted from theshared key memory region based on the block address (Ad) in theexecution AC in step S741, extracts the data (DecEData∥Kcd∥NumTr(n)),and further applies the data deciphering key (Kcd) in step S742, so asto execute deciphering of enciphered data 706 (Ec(Data;Kcd)) such asexternally-input enciphered contents or the like, and the decipheredcontents (data) 707 are output to the end entity.

Further, in step S743, processing is executed based on a number of timesprocessing command (NumTr(1)). This processing is processing of whichthe object is to destroy the registration key, to stop further usage ofservices using the execution AC, i.e., deciphering of enciphered data.That is to say, in step S744, the registration key (Kcr1) is destroyed.Destroying of the registration key is executed as processing foroverwriting the reset key at the corresponding region of the blockaddress (Ad) in the shared memory region storing the registration keyrecorded in the service providing execution attribute certificate withrestrictions on the number of times 705.

Due to this processing, the registration key (Kcr1) for deciphering theexecuting command stored in the service providing execution attributecertificate with restrictions on the number of times 705 is destroyed,so that deciphering of the execution command becomes impossible, andservice usage applying the execution AC is stopped. Following thisprocessing, the step S727 and S728 shown in FIG. 75 are performed, andthe corresponding AC is deleted from the execution AC table.

(7-2) Service Providing Execution Attribute Certificate with TransferFunction

Next, the application processing of service providing executionattribute certificate with transfer functions will be described. FIG. 78illustrates a processing sequence enabling application processing of aservice providing execution attribute certificate with transferfunctions, i.e., executing processing based on a service providingexecution attribute certificate with transfer functions between userdevices, generating a new service providing execution attributecertificate with transfer functions or service providing executionattribute certificate and sending this to another user device (transferdestination), while performing registration key destroying at own device(transfer originator), thereby enabling enciphered data (e.g.,enciphered contents) to be used at another user device.

In FIG. 78,

EE1: transfer originating user device end entity (EE) control unit,

SC1: security chip configured within EE1,

Execution AC table 1: transfer originating end entity (EE) execution ACtable control unit,

EE2: transfer destination user device end entity (EE) control unit,

SC2: security chip configured within EE2, and

Execution AC table 2: transfer destination end entity (EE) execution ACtable control unit.

First, in step S752, a transfer destination user inputs a transferrequest via the input interface of the end entity (EE), for performingtransfer processing based on a service providing execution attributecertificate with transfer functions, i.e., to enable execution ofenciphered data at the transfer destination user device. The transferrequest contains a service providing execution attribute certificatewith transfer functions ID, holder information, or usage contents(enciphered data), or service provider information or the like, asinformation for identifying the service providing execution attributecertificate with transfer functions to be applied.

Upon the end entity (EE2) receiving input of the transfer request fromthe user, in step S752, the end entity (EE2) makes a connection requestto the transfer originator end entity (EE1) which has the serviceproviding execution attribute certificate with transfer functions, andmutual authentication is executed between the security chips (SC1) and(SC2) of the user devices. This is executed as public key mutualauthentication processing described earlier with reference to FIG. 13,for example.

Upon mutual authentication being established, in step S753, the endentity (EE1) of the transfer originating user device outputs a searchrequest for the specified service providing execution attributecertificate with transfer functions, to the execution AC table 1. Thesearch key is, for example, contents information or service provider(SP) information or the like.

In step S754, the execution AC table 1 searches for the correspondingservice providing execution attribute certificate with transferfunctions based on the input key from the end entity (EE1), and outputsthe execution AC extracted from the table to the end entity (EE).

In step S755, the end entity (EE) outputs the received AC to thesecurity chip (SC), and makes an application processing request for theservice providing execution attribute certificate with transferfunctions. The security chip performs processing for the received AC instep S756, i.e., deciphering the execution command based on theregistration key obtained from the region specified by the address (Ad)stored in the execution attribute certificate (service providingexecution attribute certificate with transfer functions) (S756).

Further, in step S757, the end entity (EE1) outputs a transferprocessing request to the security chip (SC), and in step S758 the endentity (EE1) requests the transfer destination user device (EE2) topresent a group attribute certificate necessary for transfer processing.This group attribute certificate is a group attribute certificate or thelike proving the holder is a device or user group to which transfer ispermitted, managed by the service provider (SP) which has issued theservice providing execution attribute certificate with transferfunctions, for example.

The transfer destination user device end entity (EE2) transmits aspecified group attribute certificate (Gp. AC) to the transferoriginating user device end entity (EE1) in step S759, the end entity(EE1) transfers the received AC to the security chip (SC1), and thesecurity chip (SC1) verifies the group attribute certificate (S761). Theverification processing is as described earlier with reference to FIG.21 through FIG. 23, and is executed as processing including attributecertificate signature verification, corresponding public key certificateand chain public key certificate verification processing, and so forth.

In the event that verification is not established, subsequent processingis not executed and the processing is cancelled as error processing. Inthis case, processing may be performed wherein an error notification istransmitted to the transfer destination end entity (EE2).

In the event that the verification of the group attribute certificate(Gp. AC) is successful and the authenticity of the group attributecertificate (Gp. AC) has been confirmed, the flow proceeds to step S762.In step S762, an execution attribute certificate is generated andtransmitted for enabling usage of the enciphered data at the transferdestination user device. This processing is processing corresponding tothe generation and verification of the registration key generatingexecution AC and generating and transmission of the service providingexecution AC described earlier with reference to FIG. 60 and FIG. 61,with the transfer originating user device executing the processing ofthe service provider (SP) in FIG. 60 and FIG. 61.

In step S762, a new service providing execution AC, in this case aservice providing execution attribute certificate is generated, and sentto the transfer destination user device. Further, in step S763, deletionis executed for the registration key applied for deciphering theexecution command of the service providing execution attributecertificate with transfer functions, held at the transfer originatinguser device. This processing is performed by overwriting with the resetkey as described above. Note that while transfer functions have beenmentioned here, using an execution attribute certificate which does notdelete the registration key enables duplication functions instead oftransfer functions.

The details of the processing after deciphering of the service providingexecution attribute certificate with transfer functions in step S756executed at the security chip (SC1) of the transfer originating userdevice will be described with reference to FIG. 79 and FIG. 80.

The service providing execution attribute certificate with transferfunctions (AC) 711 has data of: execution commands, a block address(Ad1) in the shared key memory region 608 storing a registration key fordeciphering the execution commands, and issuer signature. The executioncommand(Ec(Sel∥Jdg(SDB)∥GenAC(GenKcr)∥GenAC(Ex)∥RevK∥DecEData∥Kcd;Kcr∥)) is ofa data configuration including a processing selection command (Sel),verification screening command (Jdg(SCB)), registration key generatingexecution AC generating command (GenAC(GenKcr), Execution AC compilingcommand (GenAC(Ex), a registration key destroying command (RevK), anenciphered data deciphering command (DecEData), and a data encipheringkey (Kcd), with these having been enciphered with the registration key(Kcr1).

The verification screening command (Jdg(SDB)) is a verificationscreening processing command of the execution AC based on the serviceinformation database (SDB). Note that the service information database(SDB) has the same data structure as the AC information necessary forproviding service, and the group information database described earlier(see FIG. 15), and holds data of the issuer, group ID, and groupinformation.

The transfer originating security chip (SC) which inputs the serviceproviding execution attribute certificate with transfer functions (AC)711 and performs processing for issuing a new service providingexecution attribute certificate with transfer functions for the transferdestination, first obtains a registration key from the shared key memoryregion 608 based on the address (Ad1) of the service providing executionattribute certificate with transfer functions (AC) 711, and deciphersthe execution command within the service providing execution attributecertificate with transfer functions (AC) 711. Next, upon input of atransfer execution trigger 712 from the end entity, the transferexecution processing from step S772 on is performed.

Now, a transfer execution trigger 712 means a request processing fromthe end entity for executing transfer processing, based on the serviceproviding execution attribute certificate with transfer functions (AC)711. The service providing execution attribute certificate with transferfunctions (AC) 711 is an execution AC applied not only to transferprocessing but also to deciphering processing of enciphered data, andwhether or not to execute the processing thereof is selected by therequest (trigger) from the end entity. Selection processing from theexecution command(Ec(Sel∥Jdg(SDB∥GenAC(GenKcr)∥GenAC(Ex)∥RevK∥DecEData∥Kcd;Kcr1)) of theservice providing execution attribute certificate with transferfunctions (AC) 711 yields the execution command(Jdg(SDB∥GenAC(GenKcr)∥GenAC(Ex)∥RevK), corresponding to the transferexecution processing, and the processing from step S772 on is executedfollowing the execution command.

In step S772, verification and screening is performed for the groupattribute certificate (Gp. AC) 713 obtained from the transferdestination following the verification screening command (Jdg(SDB)). Theverification processing is as described earlier with reference to FIG.21 through FIG. 23, and is executed as processing including attributecertificate signature verification, corresponding public key certificateand chain public key certificate confirmation processing, and so forth.In the event that verification is not established, subsequent processingis not executed and the processing is cancelled as error processing. Inthe event that the verification of the group attribute certificate (Gp.AC) is successful and the authenticity of the group attributecertificate (Gp. AC) has been confirmed, the flow proceeds to step S773.

From step S773 on, an execution attribute certificate enabling usage ofthe enciphered data at the transfer destination user devices isgenerated and transferred. This is processing corresponding to thegenerating and verification of the registration key generating executionAC described earlier with reference to FIG. 60, FIG. 61, and FIG. 63through FIG. 65, and generation and transmission of the serviceproviding execution AC, and is processing wherein the processing of theservice provider (SP) shown in FIG. 60 and FIG. 61 is executed at thetransfer originating user device.

The data 714 such as the reset key (Kreset), block address (Ad2) of theregistration key storage region of the shared key memory at the transferdestination, and public key (KpSC2) of the security chip at the transferdestination, and so forth, necessary for this processing, are obtainedfrom the transfer destination user device or the like. Based on thisnecessary data, first, in step S773, generating processing of aregistration key generating execution AC 715 is preformed following theregistration key generating execution AC compiling command(GenAC(GneKcr) in the execution command. This processing is the same asthe generating processing for the registration key generating executionAC described earlier with reference to FIG. 63.

Next, from the security chip of the transfer destination user device,the security chip of the transfer destination user device which hasreceived the registration key generating execution AC follows theexecution AC compiling command (GenAC(Ex)) in the execution command andgenerates registration key generating execution results (721 in FIG. 80)following the processing described earlier with reference to FIG. 64,and transmits this to the security chip of the transfer originating userdevice.

Upon receiving the registration key generating execution results (721 inFIG. 80) from the security chip of the transfer destination user device,the security chip of the transfer originating user device performs theprocessing according to FIG. 80, and generates a new service providingexecution attribute certificate with transfer functions (AC) 722 andtransmits this to the transfer destination user device, while executingprocessing for destroying the registration key within own shared keymemory region.

In step S781 in FIG. 80, the session key (Kcs) is applied to executedeciphering processing of the registration key generating results, andthe registration key (Kcr2) and memory region block address (Ad2) isobtained. Further, in step S782, the execution command(Ec(Sel∥Jdg(SDB)∥GenAC(GenKcr)∥GenAC(Ex)∥RevK∥DecEData∥Kcd;Kcr2)) to bestored in the new service providing execution attribute certificate withtransfer functions (AC) 722 is enciphered using the registration key(Kcr2) of the transfer destination user device. Note that the executioncommand is an execution command such as an execution program or the likeset in the new service providing execution attribute certificate withtransfer functions (AC) 722 serving as the service providing executionAC.

Further, in step S783, a signature (see FIG. 17) is generated with thesecret key (KcSC1) of the transfer originating security chip (SC1) withregard to the data obtained by the execution command having beenenciphered with the registration key (Kcr2) and the memory region blockaddress (Ad2) of the security chip at the transfer destination userdevice storing the registration key (Kcr2), thereby generating a newservice providing execution attribute certificate with transferfunctions (AC) 722, which is transmitted to the transfer destinationuser device.

Further, in step S784, the reset key is written to the address (Ad1)which had been stored in the original service providing executionattribute certificate with transfer functions (AC) 711, i.e., theregistration key storing address in the shared key memory region of thetransfer originating user device, and registration key destroyingprocessing is executed.

While the above description has been made to illustrate an example of aconfiguration for generating and sending a new service providingexecution attribute certificate with transfer functions (AC) 722 from atransfer originator to a transfer destination, this may be aconfiguration wherein a normal, i.e., a service providing executionattribute certificate (AC) without transfer functions being generatedand sent, instead of the service providing execution attributecertificate with transfer functions (AC) 722.

As described earlier, the service providing execution attributecertificate with transfer functions (AC) is an execution AC applied notonly for transfer processing but also for deciphering processing ofenciphered data. Which processing to be executed is selected by arequest (trigger) from the end entity. The processing at the securitychip in the event that the trigger is an enciphered data decipheringprocessing request will be described with reference to FIG. 81.

A service providing execution attribute certificate with transferfunctions (AC) 731 has the data of an execution command, a block address(Ad1) of the shared key memory region 608 storing the registration keyfor deciphering the execution command, and an issuer signature.

Upon receiving input of the service providing execution attributecertificate with transfer functions (AC) 731, the security chip (SC)first obtains the registration key from the shared key memory region 608based on the address (Ad1) of the service providing execution attributecertificate with transfer functions (AC) 731, and deciphers theexecution command within the service providing execution attributecertificate with transfer functions (AC) 731. Next, upon input of theenciphered data deciphering trigger 732 from the end entity, in stepS786 selection processing based on the trigger, i.e., data decipheringexecution is selected, and in step S787, the deciphering processing isexecuted.

That is to say, the execution command (DecEData∥Kcd) corresponding todata deciphering processing is obtained from the execution command(Ec(Sel∥Jdg(SDB)∥GenAC(GenKcr)∥GenAC(Ex)∥RevK∥DecEData∥Kcd;Kcr1)) of theservice providing execution attribute certificate with transferfunctions (AC) 731, and in step S787, the data deciphering key (Kcd) isapplied to execute deciphering processing of the externally-inputenciphered data (Ec(Data;Kcd)) 733 to be deciphered, and the deciphereddata 734 is output. The enciphered data (Ec(Data;Kcd)) 733 to bedeciphered is data wherein contents such as images, music, programs,etc., have been enciphered with a key (Kcd), and can be deciphered by adata deciphering key (Kcd) obtained by deciphering the storage executioncommand in the of the service providing execution attribute certificatewith transfer functions (AC) 731 with the registration key (Kcr1).

Application examples combining transfer functions and number of timesrestrictions can also be conceived. For example, setting the number oftime information of the execution AC to be transferred so as to bedecremented by one when the execution AC is transferred enables thenumber of times of transferring to be restricted. Also, applicationexamples combining duplication function and number of times restrictionscan also be conceived. For example, setting the number of timeinformation of the execution AC to be transferred so as to bedecremented by one each time duplication is performed enables the numberof times of duplication to be restricted. Now, the term duplicationmeans that performed regarding a service providing execution attributecertificate without transfer functions. Further, instead of destroyingthe service providing execution attribute certificate that has beenduplicated, providing a function wherein the number of times informationis incremented by one realizes check-in/check-out functions.

Check-in/check-out will be described in brief. Transferring a serviceusage privilege to another device is called check-out, and furthertransferring to the original device from a device which has checked-outis called check-in. In the event that the service usage privilege cannotbe transferred from a device which has checked-out to a device otherthan the original device, this is called having check-in/check-outfunctions.

(7-3) Proxy Execution Attribute Certificate

Next, the proxy execution attribute certificate will be described. Inthe (6-3) Execution attribute certificate application processing,description was made regarding a deciphering service of data with dataof which contents are enciphered, but an execution attribute certificatecan also be used to perform a service for writing an encryption keywhich only the service provider knows in the execution attributecertificate and issuing a certificate signed using the encryption key.This service providing execution attribute certificate is a proxyexecution attribute certificate.

As for the encryption key there is a method using a shared key and amethod using a secret key. The following is a description of a caseusing a secret key. In the event of verifying a certificate issued usinga proxy execution attribute certificate, the verifier must know thepublic key corresponding to the secret key. Accordingly, the issuer ofthe proxy execution attribute certificate issues a certificate for thepublic key, and the certificate holder who issues using the proxyexecution attribute certificate presents the public key certificate tothe verifier. This public key certificate is called an allograph keycertificate. The following items will each be described for proxyexecution attribute certificates

(7-3-1) Screening proxy execution attribute certificate

(7-3-2) Allograph execution attribute certificate

Each item will be described below.

(7-3-1) Screening Proxy Execution Attribute Certificate

First, the screening proxy execution attribute certificate will bedescribed. In the event of issuing an attribute certificate to an endentity with which direct exchange information from an attributecertificate authority is not easy, another end entity capable ofdirectly exchanging information is enabled by the attribute certificateauthority to perform screening for issuing by proxy, with an issuingpolicy stipulated, which is what a screening proxy execution attributecertificate is.

The overview of a screening proxy execution attribute certificate willbe described with reference to FIG. 82. FIG. 82(a) illustrates a normalattribute certificate issuing arrangement, with an attribute holderwhich is a user of an attribute certificate (AC) making an issuingrequest (S801) to, for example, an attribute authority (AA), attributecertificate registration authority (ARA), or service provider (SP), fora group attribute certificate (Gp. AC) in this case. In this case forexample, data proving the attributes of the AC user must be presented.In the above-described example, description was made with regard to anexample of presenting an already-issued group attribute certificatewhich a credit card company has issued to the AC user.

The issuer executes screening as user confirmation of the attributes andthe like of the AC user (S802), and upon determining that screening isestablished, an attribute certificate (a Gp. AC in this case) 801proving the attributes of the AC user is issued to the user (S803).

The example shown in (b) is a group attribute certificate (Gp. AC)issuing sequence applying the screening proxy execution attributecertificate which will be described below in detail.

First, a screening agent which will issue the group attributecertificate to the AC user in proxy makes a screening proxy executionattribute certificate issuing request to the original issuer, e.g., anattribute authority (AA), attribute certificate registration authority(ARA), or service provider (SP) (S811), and the attribute authority(AA), attribute certificate registration authority (ARA), or serviceprovider (SP), which is the true issuer, screens the screening agent(S812). This is executed based on data proving the attributes and thelike of the screening agent, or presenting an already-issued attributecertificate, as with conventional processing. Following establishment ofscreening, the issuer provides the screening agent with an allograph keycertificate 804 and screening proxy execution attribute certificate 803(S813).

The allograph key certificate 804 has a public key (Kpc) used forgenerating and verifying an allograph, and issuer signature data. Also,the screening proxy execution attribute certificate 803 is made up of ablock address (Ad) indicating the storage region of the registration key(Kcr) within the shared key memory of the user device of the screeningagent, and execution command (Ec(proxy screening command∥attributeinformation∥Ksa;Kcr)) enciphered with the registration key (Kcr), andissuer signature, as with the above-described execution certificate.

The secret key (Ksa) included in the execution command is a secret keyused for generating and verifying an allograph, and is a secret keycorresponding to the aforementioned public key (Kpa).

Steps S811 through S813 are a proxy commissioning phase, and followingthe proxy commissioning phase, a proxy execution phase is started. Anattribute certificate (Gp. AC) issuing request is made from the AC user(attribute holder) to the screening agent (S814). Here, a groupattribute certificate which a screening agent issues is called ascreening proxy group attribute certificate.

The screening agent which has received the screening proxy groupattribute certificate issuing request screens the user (S815). Screeningas used here may be executed based on the trust relation between thescreening agent and the AC user, and data proving the attributes of thescreening agent, or presenting of an already-issued attributecertificate, may not always be necessary. For example, in a settingwherein the screening agent is one family member and the user is thefamily, arbitrary screening can be performed based on the trust relationbetween the screening agent and the AC user, such as deeming screeningestablished upon the screening agent recognizing the family, forexample.

Following establishment of the screening the screening agent generates ascreening proxy group attribute certificate 802. The screening proxygroup attribute certificate 802 holds the information described earlierwith reference to FIG. 5, such as the public key certificate (PKC)serial number issued to the security chip of the AC holder (attributesholder), attribute information, and so forth. Further, a signature isattached applying the secret key (Ksa) stored in the execution commandin the screening proxy execution attribute certificate 802 which thescreening agent has received from the issuer earlier.

The screening agent sends the generated screening proxy group attributecertificate 802 and the allograph key certificate 804 together to the ACuser (S816). The AC user presents the screening proxy group attributecertificate 802 to the service provider (SP) for example, to proveattributes and receive services.

The flow of data between the entities including providing of serviceswill be described with reference to FIG. 83. First, in the proxycommissioning phase, a screening proxy execution AC 822 and allographkey certificate 821 are sent from the issuer 811 to the screening agent812. Next, in the proxy execution phase, a screening proxy groupattribute certificate 823 and allograph key certificate 821 are sent tothe AC user (attribute holder) 813. Further, the screening proxy groupattribute certificate 823 and allograph key certificate 821 are sentfrom the AC user (attribute holder) 813 to a verifier 814 such as theservice provider (SP), where the verifier 814 executes attributeverification of the AC user based on the screening proxy group attributecertificate 823 and allograph key certificate 821, and provides servicesunder the condition that verification is established.

Following signature verification of the allograph key certificate 821,the verifier 814 such as the service provider (SP) or the like extractsthe public key (Kpa) for allograph verification stored in the allographkey certificate 821, and executes signature verification of thescreening proxy group attribute certificate 823 applying the extractedpublic key (Kpa).

Next, the processing wherein the screening agent which has received ascreening proxy execution AC 822 and allograph key certificate 821 fromthe issuer, generates and issues the screening proxy group attributecertificate 823 based on a request from the AC user, will be describedwith reference to FIG. 84. In FIG. 84,

EE1: attribute certificate using user device end entity (EE) controlunit,

SC1: security chip configured within EE1,

EE2: screening agent user device end entity (EE) control unit,

SC2: security chip configured within EE2, and

Execution AC table: EE2 execution AC table control unit.

Note that the screening agent is not restricted to a user device, and anarrangement may be made wherein a service provider (SP) can executethis. Here, an example wherein the user device functions as a screeningagent will be described.

First, in step S821, a user which is the AC user (attribute holder)inputs a screening proxy group attribute certificate (Gp. AC) issuingrequest via the input interface of the end entity (EE1). The requestincludes information necessary for generating a screening proxy groupattribute certificate (Gp. AC), such as screening agent specifying data,information of the contents or service provider to be used, and soforth.

Upon the end entity (EE1) receiving the screening proxy group attributecertificate (Gp. AC) issuing request from the user, the end entity (EE1)makes a connection request to the end entity (EE2) of the screeningagent user device in step S822, and mutual authentication is executedbetween the security chips (SC1) and (SC2) of the user devices. This isexecuted as public key mutual authentication processing describedearlier with reference to FIG. 13, for example.

Upon mutual authentication being established, in step S823, the endentity (EE2) of the screening agent user device outputs a search requestfor the screening proxy execution AC to the execution AC table. Thesearch key is, for example, contents information or service provider(SP) information or the like.

In step S824, the execution AC table searches for the correspondingscreening proxy execution AC based on the input key from the end entity(EE2), and outputs the execution AC extracted from the table, and theallograph certificate (see 804 in FIG. 82) issued by the issuer andappended to the AC, to the end entity (EE2).

In step S825, the end entity (EE2) outputs the received AC to thesecurity chip (SC2), and makes an application processing request for theexecution attribute certificate. The security chip (SC2) performsprocessing for the received AC in step S826, i.e., deciphering theexecution command based on the registration key obtained from the regionspecified by the address (Ad) stored in the execution attributecertificate (screening proxy execution attribute certificate) in S826.

Further, in step S827, the end entity (EE1) of the AC user inputs thegroup attribute certificate for screening of the AC user to the endentity (EE2) of the screening agent, and verification processing isperformed at the security chip (SC2) of the screening agent.

As described above, the screening agent can execute the screening of theAC user based on the trust relation between the screening agent and theAC user, and while presenting data proving the attributes of thescreening agent, or presenting of an already-issued attributecertificate, may not always be necessary, an example is illustrated herewherein the screening proxy group attribute certificate is issued underthe conditions of presenting and verifying an already-issued groupattribute certificate.

Verification of the group attribute certificate by the security chip(SC2) is as described earlier with reference to FIG. 21 through FIG. 23,and is executed as processing including attribute certificate signatureverification, corresponding public key certificate and chain public keycertificate confirmation processing, and so forth. In the event thatverification is not established, subsequent processing is not executedand the processing is cancelled as error processing. In this case,processing may be performed wherein an error notification is transmittedto the AC user end entity (EE1).

In the event that the verification of the group attribute certificate(Gp. AC) is successful and the authenticity of the group attributecertificate (Gp. AC) has been confirmed, in step S830 additionalinformation (Addinfo) necessary for generating the screening proxy groupattribute certificate is input from the end entity (EE2) to the securitychip (SC2), the security chip (SC2) generates the screening proxy groupattribute certificate, and following sending thereof to the end entity(EE2), is sent to the end entity (EE1) of the AC user from the endentity (EE2) (S832). At the time of this sending processing, anallograph key certificate is attached to the generated screening proxygroup attribute certificate.

The details of processing executed at the security chip (SC2) of thescreening agent, i.e., the processing for inputting the screening proxyexecution attribute certificate and generating the screening proxy groupattribute certificate, will be described with reference to FIG. 85. Ascreening proxy execution attribute certificate (AC) 851 holds the dataof an execution command, a block address (Ad) of the shared key memoryregion 864 of the screening agent security chip (SC1) 861 storing theregistration key (Kcr) for deciphering the execution command, and anissuer signature. The execution command(Ec(Jdg(SDB)∥GenAC(Gp)∥att∥Ksa;Kcr)) contains a verification screeningcommand (Jdg(SDB)), group attribute certificate compiling command(GenAC(Gp)), attribute information (att), and allograph secret key(Ksa), with a data structure of these having been enciphered with theregistration key (Kcr).

Upon inputting the screening proxy execution attribute certificate (AC)851, first, the registration key is obtained from the shared key memoryregion 864 based on the address (Ad) of the screening proxy executionattribute certificate (AC) 851, and the execution command within thescreening proxy execution attribute certificate (AC) 851 is deciphered.Next, in step S842, verification of the group attribute certificateinput from the AC user via the end entity is performed based on theverification screening command (Jdg(SDB)). The verification processingis as described earlier with reference to FIG. 21 through FIG. 23, andis executed as processing including attribute certificate signatureverification, corresponding public key certificate and chain public keycertificate confirmation processing, and so forth. In the event thatverification is not established, subsequent processing is not executedand the processing is cancelled as error processing. In the event thatthe verification of the group attribute certificate (Gp. AC) issuccessful and the authenticity of the group attribute certificate (Gp.AC) has been confirmed, the flow proceeds to step S843.

At step S843, the screening proxy group attribute certificate isgenerated and transmitted based on the group attribute certificatecompiling command (GenAC(Gp)) within the execution command of thescreening proxy execution AC 851. This is processing corresponding tothe generating and verification of the registration key generatingexecution AC, and generating and transmission of the service providingexecution AC, described earlier with reference to FIG. 60, FIG. 61, andFIG. 63 through FIG. 65, and is the same as processing at the securitymodule of the service provider (SP) in FIG. 63 through FIG. 65.Preferably, additional information (addinfo) 853 is attached to thescreening proxy attribute certificate indicating that it is a screeningproxy attribute certificate, thereby indicating difference to normalattribute certificates.

In step S844, the allograph secret key (Ksa) obtained from the executioncommand of the screening proxy execution attribute certificate 851 isapplied to sign the additional information (addinfo) and attributeinformation (att), thereby generating a screening proxy group attributecertificate 854, which is transmitted to the AC user (attribute holder)via the end entity (EE2). Note that the allograph key certificate isattached to the generated screening proxy group attribute certificateand sent to the AC user.

The AC user presents the screening proxy group attribute certificateissued by the above processing and the allograph key certificate to averifier such as a service provider or the like, and receives servicesunder the condition that the attributes are verified. The verifier suchas a service provider or the like applies a key which can be obtainedfrom the allograph key certificate so as to be able to verify thesignature of the screening proxy group attribute certificate.

An example of applying the above-described screening proxy groupattribute certificate is issuing screening proxy group attributecertificates regarding which the number of accounts is limited. In theevent that a service provider (SP) is to provide service to all familymembers of the family of Mr. A, whether or not the family of Mr. A isscreened using a group attribute certificate (Gp. AC) proving the familyof household A.

At this time, while attribute screening with high reliability could berealized if an attribute certificate (AC) issued by a third-partyorganization having basic citizen information, such as a city hall, wereused as the group attribute certificate (Gp. AC) proving membership inhousehold A, such attribute certificates may not be available for use.On the other hand, Mr. A himself issuing a group attribute certificate(Gp. AC) proving membership in household A is possible depending on thewill of Mr. A. However, it is unlikely that the individual Mr. A couldbe determined to be trustworthy as an attribute authority (AA) which isthe true issuing entity of an attribute certificate.

Accordingly, a screening proxy group attribute certificate is issuedapplying the above-described screening proxy execution AC. In this case,Mr. A issues a screening proxy group attribute certificate applying thescreening proxy execution AC, serving as the screening agent as therepresentative of the family of Mr. A. The screening for issuing thescreening proxy group attribute certificate can be realized based on thetrust relation between the screening agent (Mr. A) and the AC user (thefamily of Mr. A), and presenting data proving the attributes of thescreening agent, or presenting of an already-issued attributecertificate, may not always be necessary. Thus, screening proxy groupattribute certificates can be issued based on the trust relation betweenthe screening agent and the AC user, such as deeming screening to havebeen established once the fact that the screening agent is family isrecognized.

However, there is the possibility that Mr. A might issue a screeningproxy group attribute certificate to a friend Mr. B who is not a familymember, but with attributes showing to be a family member of Mr. A. Inorder to reduce the possibility of such cases, a restriction can beplaced on the number of screening proxy group attribute certificatesissued, such as with settings wherein the upper limit=5 for example,thereby preventing excessive unauthorized use.

The above-described screening proxy group attribute certificate issuingprocessing arrangement can be realized in the same way for groupattribute certificates wherein devices owned by Mr. A are set as agroup, and Mr. A can issue screening proxy issue group attributecertificates to each of his own devices based on the screening proxyexecution AC, with Mr. A serving as the screening agent with thescreening proxy group attribute certificate applying the screening proxyexecution AC.

Further, an example of processing applying a screening proxy groupattribute certificate is an example of application to voting in anelection. Using screening proxy group attribute certificates enables thevoter to be able to vote such that none other than the candidate votedfor can tell who the voter voted for, not even the election boardmembers.

In this processing example, let us say that

Screening agent: voter, and

AC user (attribute holder): candidate.

This voting system is a model wherein a voter communicates with acandidate instead of the election board at the time of voting, unlike anactual election. First, the service provider (SP) issues a screeningproxy execution Ac to the voter. A candidate tells the voter a uniqueidentification value, i.e., an identification value which is differentfrom all other votes, and issues a screening proxy group attributecertificate (Gp. AC) having that number and the PKC serial No. of thecandidate whom the voter intends to vote for as attributes, based on thescreening proxy execution AC, and sends this to the candidate. Thescreening proxy execution AC is automatically destroyed followinggenerating the screening proxy group attribute certificate (Pg. AC).

The number of votes is counted based on the number of screening proxygroup attribute certificates (Gp. AC) issued to each candidate, therebydetermining the winner. All screening proxy group attribute certificateswith the same identification number are viewed as having been copied,and only count as one vote.

(7-3-2) Allograph Execution Attribute Certificate

Next, the allograph execution attribute certificate will be described.An Allograph execution AC is an execution attribute certificate enablingthe AC user (attribute holder) himself/herself to issue group attributecertificates (allograph group attribute certificate) for application toown service.

The overview of the allograph execution attribute certificate will bedescribed with reference to FIG. 86. FIG. 86(a) illustrates the issuingand application processing arrangement of a normal attributecertificate. A request for issuing an attribute certificate, a groupattribute certificate (Gp. AC) in this case, is made from the attributeholder which is the user of the attribute certificate (AC), to anissuer, e.g., an attribute authority (AA), attribute certificateregistration authority (ARA), or service provider (SP) (S901). In thiscase for example, presenting data proving the attributes of the AC useris necessary. In the above-described examples, an example of presentingan already-issued group attribute certificate which a credit cardcompany for example, has already issued to the AC user, as described.

The issuer performs screening (S902) as user confirmation, forattributes of the AC user and so forth, and upon determination beingmade that screening has been established, an attribute certificate 921proving the attributes of the AC user (a Gp. AC here) is issued to theuser (S903).

The AC user (attribute holder) can receive application of service bypresenting the issued group attribute certificate (Gp. AC) to a verifiersuch as a service provider (SP), wherein the AC user (attribute holder)presents the group attribute certificate (Gp. AC) (S905) in response toa group attribute certificate (Gp. AC) presentation request (S904) fromthe verifier, whereby verification of the group attribute certificate(Gp. AC) is performed by the verifier (S906).

The example shown in (b) is a group attribute certificate (Gp. AC)issuing and application processing sequence applying the allographexecution attribute certificate, which will be described now in detail.

First, the AC user (attribute holder) makes a request for issuing anallograph execution attribute certificate (AC) to an issuer, e.g., anattribute authority (AA), attribute certificate registration authority(ARA), or service provider (SP) (S911). The issuer performs screening ofthe data proving the attributes of the AC user, e.g., an already-issuedgroup attribute certificate or the like (S912), and upon determiningthat screening has been established, issues an allograph executionattribute certificate 923. The issuer also provides the allograph keycertificate 924 to the AC user (attribute holder) at this time.

The allograph key certificate 924 has a public key (Kpa) used forgenerating and verifying an allograph, and issuer signature data. Also,as with the execution certificate described above, the allographexecution attribute certificate 923 is made up of a block address (Ad)indicating the storage region of the registration key (Kcr) within theshared key memory of the user device of the screening agent, andexecution command (Ec(allograph command∥attribute information∥Ksa;Kcr))enciphered with the registration key (Kcr), and issuer signature.

The secret key (Ksa) included in the execution command is a secret keyused for generating and verifying an allograph, and is a secret keycorresponding to the aforementioned public key (Kpa).

Steps S911 through 913 are an issuing phase, and following the issuingphase, a verifying phase is started. In step S914, a verifier such as aservice provider (SP) executes a presentation request for the allographgroup attribute certificate (Gp. AC) to the AC user (attribute holder).At the time of this presentation request, the verifier such as a serviceprovider (SP) or the like transmits a verifying random number (Ra) forthe allograph group attribute certificate (Gp. AC) to the AC user(attribute holder).

In step S915, the AC user (attribute holder) applies the allograph groupattribute certificate received earlier from the issuer to generate anallograph group attribute certificate (Gp. AC) 922, in response to anallograph group attribute certificate (Gp. AC) presentation request fromthe verifier such as a service provider (SP). The details of thisgenerating processing will be described later. The allograph groupattribute certificate (Gp. AC) 922 includes the verifying random number(Ra) received from the verifier in the information such as the serialnumber of the public key certificate (PKC) of the AC user (attributeholder), attribute information, etc., and a signature is attached usingthe secret key (Ksa) stored in the execution command of the allographexecution attribute certificate 923 received from the issuer earlier.

The AC user (attribute holder) sends the generated allograph groupattribute certificate 922 and the allograph key certificate 924 togetherto the verifier (S916). After signature verification of the allographkey certificate 924, the verifier extracts the allograph verifyingpublic key (Kpa) stored in the allograph key certificate 924, andapplies the extracted public key (Kpa) to execute signature verificationof the allograph group attribute certificate 922. Further, verifying amatch between the random number stored in the allograph group attributecertificate and the random number generated by itself earlier allowsconfirmation that the allograph group attribute certificate has beenpresented in response to the request of the verifier, by thisverification.

The flow of data among the entities including service providing will bedescribed with reference to FIG. 87. first, in the issuing phase, anallograph key certificate 941 and allograph execution attributecertificate 942 are sent to the AC user (attribute holder) from theissuer 931 to the AC user (attribute holder) 932. Next, upon a servicerequest being made from the AC user (attribute holder) 932 to a verifier933 such as the service provider (SP) or the like, the verifier 933makes an allograph group attribute certificate (Gp. AC) presentationrequest to the AC user (attribute holder) 932. At the time of thispresentation request, the verifier 933 transmits a verifying randomnumber (Ra) for the allograph group attribute certificate (Gp. AC) tothe AC user (attribute holder) 932.

The AC user (attribute holder) 932 applies the allograph group attributecertificate received earlier from the issuer to generate an allographgroup attribute certificate (Gp. AC) 943, in response to an allographgroup attribute certificate (Gp. AC) presentation request from theverifier 933. The allograph group attribute certificate (Gp. AC) 943includes the verifying random number (Ra) received from the verifier inthe information such as the serial number of the public key certificate(PKC) of the AC user (attribute holder) 932, attribute information,etc., and a signature is attached using the secret key (Ksa) stored inthe execution command of the allograph execution attribute certificate942 received from the issuer earlier.

Next, the AC user (attribute holder) 932 sends the allograph groupattribute certificate 943 and the allograph key certificate 941 togetherto the verifier, and the verifier executes attribute verification of theAC user based on the allograph group attribute certificate 943 and theallograph key certificate 941, and provides services under the conditionthat verification is established.

Following signature verification of the allograph key certificate 941,the verifier 933 such as a service provider (SP) extracts the allographverifying public key (Kpa) stored in the allograph key certificate 941,and applies the extracted public key (Kpa) to execute signatureverification of the allograph group attribute certificate 943, andverifies the allograph group attribute certificate 943 by collation ofthe stored random number.

Next, the details of processing executed by an AC user having theallograph group attribute certificate and the allograph key certificateissued by the issuer at the time of a allograph group attributecertificate presentation request from a verifier such as a serviceprovider (SP) or the like, will be described with reference to FIG. 88.In FIG. 88,

SP: service provider control unit for executing verification ofattribute certificates,

SM: security module of SP

EE: attribute certificate using user device end entity (EE) controlunit,

SC: security chip configured within EE, and

Execution AC table: execution AC table control unit of EE.

The processing shown in FIG. 88 illustrates the processing followingmutual authentication having been established between the securitymodule (SM) of the service provider (SP) and the security chip (SC) ofthe user device.

Following establishment of mutual authentication, the service provider(SP) makes a request to generate a random number (S951) to be applied atthe time of attribute certificate verification of the security module(SM), and in step S952, the security module (SM) generates a randomnumber in response to the request, that is output to the serviceprovider (SP).

In step S953, the service provider (SP) makes a allograph groupattribute certificate presentation request to the end entity (EE). Atthis time, the service provider (SP) transmits the verifying randomnumber (Ra) of the allograph group attribute certificate (Gp. AC) to theend entity (EE) as well.

In step S954, the end entity (EE) makes a search of the execution ACtable for an allograph execution attribute certificate to be applied forgenerating the allograph group attribute certificate (Gp. AC), and instep S955, the execution AC table outputs the allograph executionattribute certificate and the corresponding allograph key certificate tothe end entity (EE).

In step S956, the end entity (EE) requests application processing of theallograph execution attribute certificate, i.e., allograph groupattribute certificate generating processing, of the security chip (SC),and in step S958, the security chip (SC) executes the allograph groupattribute certificate generating processing. The details of theallograph group attribute certificate generating processing are the sameas the processing of the allograph group attribute certificate based onthe allograph execution attribute certificate described with referenceto FIG. 85 earlier. Note however, that the random number (Ra) receivedfrom the verifier is stored in the allograph group attributecertificate.

In step S958, the security chip (SC) sends the generated allograph groupattribute certificate to the end entity (EE). In step S959, the endentity (EE) transmits the allograph group attribute certificate, and theallograph key certificate already received from the issuer earlier, tothe security module (SM) of the service provider side.

Upon the security module (SM) of the service provider side receiving theallograph group attribute certificate and the allograph key certificate,the public key (Kpa) for allograph verification stored in the allographkey certificate is extracted, the extracted public key (Kpa) is appliedto perform signature verification of the allograph group attributecertificate, and also verification based on collation processing of thestored random number in the allograph group attribute certificate, andthe verification results are notified to the service provider (SP). Theservice provider (SP) provides service in the event that verification isestablished according to the response results, and in the event thatverification is not established service stopping processing isperformed.

A normal attribute certificate is an example of applying an allographexecution attribute certificate. That is to say, using an allographexecution attribute certificate instead of a normal attributecertificate allows the destruction processing function of the executionattribute certificate to be used, so the trouble of revocationprocessing such as making reference to a list for destruction each timeverification is performed, and reduction in reliability, can be solved.

A further application example is an allograph attribute certificatewherein the number of times of proving attributes is restricted. That isto say, using an allograph execution attribute certificate having numberof times restricting functions as a group attribute certificate forpermitting providing of services other than deciphering of enciphereddata as well, can enable restricted services to be provided without thetrouble of having an external entity such as a server to hold number oftimes information, and without reducing processing efficiency.

[(8) Configuration of Entities]

Next, a configuration example of entities serving as informationprocessing devices, such as the end entity (EE) having a security chip(SC) or a user identification device (UID) having security chip (SC), ora service provider (SP) or the like serving as a user device forexecuting the above-described processing, i.e., generating, verifying,transmission/reception, etc., will be described with reference todrawings.

The end entity information processing devices such as user devices andservice providers and the like each have a CPU for performing varioustypes of data processing and control, and also have communication meanscapable of communicating with other entities, and can be configured asvarious types of information processing device such as servers, PCs,PDAs, portable communication terminal devices, and so forth, forexample.

FIG. 89 illustrates an information processing device configurationexample. Note that the configuration example shown in FIG. 89 is but anexample, and that the entities do not necessarily need to have all ofthe functions shown here. The CPU (Central Processing Unit) 951 shown inFIG. 89 is a processor for executing various application programs and anOS (Operating System). The ROM (Read-Only-Memory) 952 stores programs tobe executed by the CPU 951, and fixed data such as computationparameters. The RAM (Random Access Memory) 953 is used as a storage areaand work area for programs executed by the processing of the CPU 951,and parameters which change as necessary according to processing of theprograms.

The HDD 954 executes control of a hard disk, and executes processing forstoring and reading various types of data and programs to and from thehard disk. The security chip 962 is of a configuration having ananti-tampering structure as described above, and has an encipheringprocessing unit, a data processing unit, and memory for storing key datanecessary for encipherment processing, verification of attributecertificates as privilege confirmation processing, execution ofgenerating processing, and so forth.

A bus 960 is configured of a PCI (Peripheral Component Interface) bus orthe like, and enables data transfer with the input/output devices viathe modules and input/output interface 961.

An input unit 955 is configured of a keyboard, pointing device, etc.,for example, and is operated by the user to input various types ofcommands and data to the CPU 951. The output unit 956 is a CRT, liquidcrystal display, etc., and displays various types of information bytext, images, etc.

A communication unit 957 is configured of an entity connected to adevice such as a network interface, connected device interface, etc.,realizing communication processing with a service provider or the likefor example, and processing for transmitting data supplied from storageunits, data processed by the CPU 951, and enciphered data, or receivingdata from other entities, is carried out under control of the CPU 951.

A drive 958 is a drive for executing recording and reproduction ofremovable recording media 959 such as flexible disks, CD-ROM (CompactDisc Read Only Memory), MO (Magneto optical) disks, DVD (DigitalVersatile Disc), magnetic disks, semiconductor memory, or the like, andreproduces programs or data from the removable recording media 959 andstores programs or data to the removable recording media 959.

In the event of reading out programs or data recorded in a recordingmedium and executing or processing at the CPU 951, the program or datathat has been read out is supplied to the RAM 953, connected forexample, via the interface 961 and bus 960.

Programs for executing the processing at the user devices, serviceprovider, etc., included in the above description, is either stored inROM 952 for example and processed by the CPU 951, or stored in the harddisk and supplied to the CPU 951 via the HDD 954 to be executed.

The present invention has been described so far with reference toparticular embodiments. However, it is self-evident that one skilled inthe art can make various modifications and substitutions withoutdeparting from the spirit and scope of the present invention. That is tosay, the present invention has been disclosed through examples, andshould not be interpreted restrictively. The essence of the inventionshould be determined based on the section of the Claims of theinvention, listed at the opening.

Note that the series of processing described in the specification can beexecuted by hardware, software, of a combined configuration of both. Inthe event of executing the processing with software, a programdescribing the processing sequence is installed in memory of a computerbuilt into dedicated hardware and executed, or the program is installedin a general-purpose computer capable of various types of processing, soas to be executed.

For example, a program can be recorded in a hard disk or ROM (Read OnlyMemory) serving as recording media beforehand. Or, the program can betemporarily or permanently stored (recorded) in flexible disks, CD-ROM(Compact Disc Read Only Memory), MO (Magneto optical) disks, DVD(Digital Versatile Disc), magnetic disks, semiconductor memory, or likeremovable recording media. Such removable recording media can beprovided as so-called packaged software.

Also, besides being installed from removable recording media such asdescribed above into a computer, the program can be transferredwirelessly to the computer from a download site, transferred to thecomputer via cable through a network such as a LAN (Local Area Network)or Internet or the like, with the computer receiving programs beingtransferred in such a way and installing in a recording medium such as abuilt-in hard disk or the like.

Further, note that the various types of processing described in thespecification are not restricted to being executed in the time-sequencedescribed, but may be executed in parallel or individually, according tothe processing capabilities of the device executing the processing, oras necessary. Also note that the term system as used in the presentspecification is a logical group of multiple devices, and is notrestricted to the component devices being within a single housing.

INDUSTRIAL APPLICABILITY

As described above, according to the privilege managing system,information processing device, and method, of the present invention, agroup attribute certificate which has, as stored information, groupidentification information corresponding to a group which is a set ofcertain devices or certain users, and also has affixed an electronicsignature of an issuer, is issued to a service reception entity, andverification is performed by means of signature verification for of thegroup attribute certificate presented from the user device regardingwhether or not there has been tampering, screening is performedregarding whether or not this is a service-permitted group based ongroup identification information stored in the group attributecertificate, and determination is made regarding whether or not servicecan be provided, based on the screening; accordingly, centralizedprivilege confirmation corresponding to various user sets or device setscan be made, so management of individual privilege information can beomitted, thereby enabling effective privilege management.

Further, according to the privilege managing system, informationprocessing device, and method, of the present invention, determiningprocessing regarding whether or not service can be provided is enabledapplying a group information database wherein a group identifier andpermitted service information for members belonging to the group arecorrelated, thereby enabling detailed differentiation of settingprivileges for each group.

Further, according to the privilege managing system, informationprocessing device, and method, of the present invention, screeningregarding whether or not the object of service permission is executedfor each of a plurality of sets of different group identificationinformation obtained from a plurality of group attribute certificatesbased on a plurality of different group definitions presented by theuser device, and determining processing regarding whether or not servicecan be provided can be executed under the condition that all groupidentification sets are the object of service permission, therebyenabling various arrangements of privilege settings, such as providingservices based on multiple conditions such as a group set correspondingto a group set for devices and a group set for users, and so forth.

Further, according to the access privilege managing system,communication processing device, and method, of the present invention,based on group identification information stored in a group attributecertificate which has, as stored information, group identificationinformation corresponding to a group which is a set of certaincommunication devices or certain users, and also has affixed anelectronic signature of an issuer, screening is performed regardingwhether or not the access requesting device is a device which belongs toan access-permitted group, and determination regarding whether or notaccess can be permitted is made based on the screening, therebypermitting access only to an access requesting communication processingdevice group which users or user devices which are a member of a grouparbitrarily set by users having communication processing devices.

Further, according to the access privilege managing system,communication processing device, and method, of the present invention,screening is performed regarding whether or not the access requestingdevice is a device owned by a user belonging to an access-permittedgroup, based on a group attribute certificate issued to a useridentification device which is an individual identification devicemaking up the access requesting device, and determination is maderegarding whether or not access can be permitted, based on thescreening, so even in the event that the communication processing devicehas been changed, access is permitted in the screening based on thegroup attribute certificate issued to the user identification devicewhich is the individual identification device, and cases wherein accessis forbidden due to changing the communication processing device can beprevented.

According to the data processing system, data processing device, andmethod, of the present invention, in a data processing system forexecuting data processing between multiple mutually communicabledevices, a data processing requesting device, which requests dataprocessing to the other device with which communication is being made,transmits to a data processing requested device a group attributecertificate which has, as stored information, group identificationinformation corresponding to a group which is a set of certain devicesor certain users, verification processing of the received groupattribute certificate is performed at the data processing requesteddevice, determination is made regarding whether or not the dataprocessing requesting device has data processing requesting privilegesbased on the verification, and data processing is performed based ondetermination of privileges, so cases wherein processing is executed bya wrong device or user is prevented, and proper data processing based onvalid privileges is carried out.

Further, according to the data processing system, data processingdevice, and method, of the present invention, with an arrangementwherein a plurality of data processing devices request data processingof the other device with which communication is being made, therebycollaboratively executing data processing, each of the devices transmitsthe group attribute certificate stored in itself at the time of dataprocessing requesting of the other device with which communication isbeing made, and under the condition of verification being established atthe receiving device, processing corresponding to the data processingrequest is mutually executed, thereby enabling proper collaborative dataprocessing accompanying communication between the plurality of dataprocessing devices.

Further, according to the data processing system, data processingdevice, and method, of the present invention, a maintenance executingdevice and a maintenance service receiving device each store controlattribute certificate and a service attribute certificate, with theattribute certificates being exchanged at the time of executingmaintenance service, and mutually verified and screened at each device,wherein maintenance processing is performed under the condition thatscreening has been established, so maintenance processing can berealized in a sure manner within the set privilege ranges of each.

1. A privilege management system for managing service receptionprivileges of user devices; wherein a user device which is a servicereception entity holds a group attribute certificate which has, asstored information, group identification information corresponding to agroup which is a set of certain devices or certain users, and also hasaffixed an electronic signature of an issuer; and wherein a serviceprovider which is a service providing entity has a configuration forexecuting verification, by means of signature verification, of the groupattribute certificate presented from said user device regarding whetheror not there has been tampering, performing screening regarding whetheror not this is a service-permitted group based on group identificationinformation stored in said group attribute certificate, and executingdetermination regarding whether or not service can be provided, based onsaid screening.
 2. A privilege management system according to claim 1,wherein said group attributes certificate is a certificate issued to auser device corresponding to a device or a user, under the conditionsthat mutual authentication is established between a group attributescertificate issuing entity and the user device, and that the device oruser to which the certificate is to be issued is following an issuancepolicy permitted by said service provider.
 3. A privilege managementsystem according to claim 1, wherein the issuing processing for a newgroup attributes certificate is of a configuration carried out under thecondition that verification is established at the group attributescertificate issuing entity regarding an already-issued group attributescertificate which the user device already holds.
 4. A privilegemanagement system according to claim 1, wherein said service provider isof a configuration having a group information database wherein saidgroup identifier and permitted service information for members belongingto the group are correlated, wherein said group information database issearched based on the group identification information stored in saidgroup attributes certificate presented by said user device, anddetermining processing regarding whether or not service can be providedis executed.
 5. A privilege management system according to claim 1,wherein said service provider is of a configuration wherein screeningregarding whether or not the object of service permission is executedfor each of a plurality of sets of different group identificationinformation obtained from a plurality of group attribute certificatesbased on a plurality of different group definitions presented by saiduser device, and determining processing regarding whether or not servicecan be provided is executed under the condition that all groupidentification sets are the object of service permission.
 6. A privilegemanagement system according to claim 1, wherein said service provider isof a configuration wherein screening, regarding whether or not theobject of service permission is executed for first group identificationinformation obtained from a first group attribute certificate based ongroup definitions from said user device wherein devices are groupmembers, and screening regarding whether or not the object of servicepermission is executed for second group identification informationobtained from a second group attribute certificate based on groupdefinitions from said user device wherein devices are group users, anddetermining processing regarding whether or not service can be providedis executed under the condition that all group identification sets arethe object of service permission.
 7. A privilege management systemaccording to claim 1, wherein said user device is of a configurationincluding an end entity as a device for executing communication withsaid service provider, and a user identification device as an individualidentification device; wherein said group attribute certificate isissued individually to each of said end entity and user identificationdevice, with issuing processing being carried out under the conditionthat mutual authentication has been established between the groupattribute certificate issuing entity and said end entity or said useridentification device.
 8. A privilege management system according toclaim 1, of a configuration wherein said group attribute certificate isan attribute certificate issued by an attribute authority, and a groupidentifier is stored in an attribute information filed within theattribute certificate.
 9. A privilege management system according toclaim 1, wherein said group attribute certificate is of a configurationstoring link information regarding a public key certificatecorresponding to said group attribute certificate; and wherein saidservice provider is of a configuration wherein verification of thepublic key certificate obtained by said link information is alsoexecuted at the time of performing verification of said group attributecertificate.
 10. An information processing device for executing dataprocessing as service providing processing, comprising: a data receptionunit for receiving a group attribute certificate which has, as storedinformation, group identification information corresponding to a groupwhich is a set of certain devices or certain users, and also has affixedan electronic signature of an issuer; and a group attribute certificateverification processing unit for executing verification, by means ofsignature verification, of the group attribute certificate regardingwhether or not there has been tampering, performing screening regardingwhether or not this is a service-permitted group based on groupidentification information stored in said group attribute certificate,and executing determination regarding whether or not service can beprovided, based on said screening.
 11. An information processing deviceaccording to claim 10, of a configuration further comprising a groupinformation database wherein said group identifier and permitted serviceinformation for members belonging to the group are correlated; whereinsaid group attribute certificate verification processing unit searchessaid group information database based on the group identificationinformation stored in said group attributes certificate presented bysaid user device, and executes determining processing regarding whetheror not service can be provided.
 12. An information processing deviceaccording to claim 10, wherein said group attribute certificateverification processing unit is of a configuration wherein screeningregarding whether or not the object of service permission is executedfor each of a plurality of sets of different group identificationinformation obtained from a plurality of group attribute certificatesbased on a plurality of different group definitions presented by saiduser device, and determining processing regarding whether or not servicecan be provided is executed.
 13. A privilege management method formanaging service reception privileges of user devices, comprising: as anexecution step at a user device which is a service reception entity, astep for transmitting to a service provider which is a service providingentity a group attribute certificate which has, as stored information,group identification information corresponding to a group which is a setof certain devices or certain users, and also has affixed an electronicsignature of an issuer; and, as an execution step at said serviceprovider, a step for performing verification, by means of signatureverification, of the group attribute certificate presented from saiduser device regarding whether or not there has been tampering,performing screening regarding whether or not this is aservice-permitted group based on group identification information storedin said group attribute certificate, and executing determinationregarding whether or not service can be provided, based on saidscreening.
 14. A privilege management method according to claim 13,further comprising a group attribute certificate issuing processing stepfor issuing said group attributes certificate to a user devicecorresponding to a device or a user; wherein said group attributecertificate issuing processing step is a processing step for issuing thegroup attribute certificate to a user device corresponding to a deviceor a user under the conditions that mutual authentication is establishedbetween a group attributes certificate issuing entity and the userdevice, and that the device or user to which the certificate is to beissued is following an issuance policy permitted by said serviceprovider.
 15. A privilege management method according to claim 14,wherein said group attribute certificate issuing processing stepincludes a verification processing step regarding an already-issuedgroup attributes certificate which the user device already holds,wherein issuing of a group attributes certificate is carried out underthe condition that said verification is established.
 16. A privilegemanagement method according to claim 13, wherein said service provideris of a configuration having a group information database wherein saidgroup identifier and permitted service information for members belongingto the group are correlated, wherein said group information database issearched based on the group identification information stored in saidgroup attributes certificate presented by said user device, anddetermining processing regarding whether or not service can be providedis executed.
 17. A privilege management method according to claim 13,wherein said service provider is of a configuration wherein screeningregarding whether or not the object of service permission is executedfor each of a plurality of sets of different group identificationinformation obtained from a plurality of group attribute certificatesbased on a plurality of different group definitions presented by saiduser device, and determining processing regarding whether or not servicecan be provided is executed under the condition that all groupidentification sets are the object of service permission.
 18. Aprivilege management method according to claim 13, wherein at saidservice provider, screening regarding whether or not the object ofservice permission is executed for first group identificationinformation obtained from a first group attribute certificate based ongroup definitions from said user device wherein devices are groupmembers, and screening regarding whether or not the object of servicepermission is executed for second group identification informationobtained from a second group attribute certificate based on groupdefinitions from said user device wherein devices are group users, anddetermining processing regarding whether or not service can be providedis executed under the condition that all group identification sets arethe object of service permission.
 19. A privilege management methodaccording to claim 13, wherein said group attribute certificate is of aconfiguration storing link information regarding a public keycertificate corresponding to said group attribute certificate; andwherein said service provider is of a configuration wherein verificationof the public key certificate obtained by said link information is alsoexecuted at the time of performing verification of said group attributecertificate.
 20. An information processing method for an informationprocessing device for executing data processing as service providingprocessing, said method comprising: a certificate reception step forreceiving from a service providing device, a group attribute certificatewhich has, as stored information, group identification informationcorresponding to a group which is a set of certain devices or certainusers, and also has affixed an electronic signature of an issuer, as anattribute certificate to be applied to service usage privilegeconfirmation processing; and a group attribute certificate verificationprocessing step for executing verification, by means of signatureverification of the group attribute certificate, regarding whether ornot there has been tampering, performing screening regarding whether ornot this is a service-permitted group based on group identificationinformation stored in said group attribute certificate, and executingdetermination regarding whether or not service can be provided, based onsaid screening.
 21. An information processing method according to claim20, said information processing device further comprising a groupinformation database wherein said group identifier and permitted serviceinformation for members belonging to the group are correlated; whereinsaid group attribute certificate verification processing step includes astep for searching said group information database based on the groupidentification information stored in said group attributes certificatepresented by said user device, and executing determining processingregarding whether or not service can be provided.
 22. An informationprocessing method according to claim 20, wherein said group attributecertificate verification processing step includes a step for executingscreening regarding whether or not the object of service permission isexecuted for each of a plurality of sets of different groupidentification information obtained from a plurality of group attributecertificates based on a plurality of different group definitionspresented by said user device, and executing determining processingregarding whether or not service can be provided under the conditionthat all group identification sets are the object of service permission.23. A computer program for effecting execution of privilege managementprocessing for managing service reception privileges of user devices,said program comprising: a certificate reception step for receiving froma service providing device, a group attribute certificate which has, asstored information, group identification information corresponding to agroup which is a set of certain devices or certain users, and also hasaffixed an electronic signature of an issuer, as an attributecertificate to be applied to service usage privilege confirmationprocessing; and a group attribute certificate verification processingstep for executing verification, by means of signature verification ofthe group attribute certificate, regarding whether or not there has beentampering, performing screening regarding whether or not this is aservice-permitted group based on group identification information storedin said group attribute certificate, and executing determinationregarding whether or not service can be provided, based on saidscreening.
 24. An access privilege management system for executingaccess restrictions between communication devices having communicationfunctions; wherein an access requesting device stores, in storage means,a group attribute certificate which has, as stored information, groupidentification information corresponding to a group which is a set ofcertain communication devices or certain users, and also has affixed anelectronic signature of an issuer; and wherein an access requesteddevice, which is the object of an access request from said accessrequesting device, executes verification, by means of signatureverification, of the group attribute certificate presented from saidaccess requesting device regarding whether or not there has beentampering, performing screening regarding whether or not said accessrequesting device is a device which belongs to an access-permitted groupbased on group identification information stored in said group attributecertificate, and executes determination regarding whether or not accesscan be permitted, based on said screening.
 25. An access privilegemanagement system according to claim 24, wherein said access requesteddevice has a configuration for performing screening regarding whether ornot said access requesting device is an end entity belonging to anaccess-permitted group, based on a group attribute certificate issued tothe end entity which is an access executing device making up said accessrequesting device, and executing determination regarding whether or notaccess can be permitted, based on said screening.
 26. An accessprivilege management system according to claim 24, wherein said accessrequested device has a configuration for performing screening regardingwhether or not said access requesting device is a device owned by a userbelonging to an access-permitted group, based on a group attributecertificate issued to a user identification device which is anindividual identification device making up said access requestingdevice, and executing determination regarding whether or not access canbe permitted, based on said screening.
 27. An access privilegemanagement system according to claim 24, of a configuration wherein saidaccess requesting device and said access requested device have securitychips with anti-tampering configurations, with mutual authenticationbeing executed between the mutual security chips, and wherein, under thecondition that mutual authentication has been established, said accessrequested device executes signature verification of the group attributecertificate presented from said access requesting device, and screeningregarding whether or not the device belongs to an access-permittedgroup.
 28. An access privilege management system according to claim 24,of a configuration wherein said access requested device receives from adevice an issuing request for a group attribute certificate certifyingthat the device is an access-permitted group member; and wherein, underthe conditions that mutual authentication between devices has beenestablished and that the group attribute certificate issue requestingdevice is following an issuance policy permitted by said accessrequested device, issues a group attribute certificate to a devicecorresponding to a device or a user, certifying that the device is anaccess-permitted group member.
 29. An access privilege management systemaccording to claim 24, of a configuration wherein said access requesteddevice receives from a device an issuing request for a group attributecertificate certifying that the device is an access-permitted groupmember; and wherein, under the conditions that mutual authenticationbetween devices has been established and that verification and screeningis established for an already-issued group attribute certificate alreadyheld by the group attribute certificate issue requesting device, issuesa group attribute certificate to a device corresponding to a device or auser, certifying that the device is an access-permitted group member.30. An access privilege management system according to claim 24, whereinsaid group attribute certificate is of a configuration storing linkinformation regarding a public key certificate corresponding to saidgroup attribute certificate; and wherein said access requesting deviceis of a configuration wherein verification of the public key certificateobtained by said link information is also executed at the time ofperforming verification of said group attribute certificate.
 31. Acommunication processing device for executing access restrictionprocessing, comprising: a reception unit for receiving, from an accessrequesting device, a group attribute certificate which has, as storedinformation, group identification information corresponding to a groupwhich is a set of certain communication devices or certain users, andalso has affixed an electronic signature of an issuer; and an accessprivilege determination processing unit for executing group attributecertificate verification processing functions, for executingverification, by means of signature verification, of the group attributecertificate received from said access requesting device regardingwhether or not there has been tampering, performing screening regardingwhether or not said access requesting device is a device which belongsto an access-permitted group based on group identification informationstored in said group attribute certificate, and executing determinationregarding whether or not access can be permitted, based on saidscreening.
 32. A communication processing device according to claim 31,wherein said access privilege determination processing unit has aconfiguration for performing screening regarding whether or not saidaccess requesting device is an end entity belonging to anaccess-permitted group, based on a group attribute certificate issued tothe end entity which is an access executing device at said accessrequesting device, and executing determination regarding whether or notaccess can be permitted, based on said screening.
 33. A communicationprocessing device according to claim 31, wherein said access privilegedetermination processing unit has a configuration for performingscreening regarding whether or not said access requesting device is adevice owned by a user belonging to an access-permitted group, based ona group attribute certificate issued to a user identification devicewhich is an individual identification device making up said accessrequesting device, and executing determination regarding whether or notaccess can be permitted, based on said screening.
 34. A communicationprocessing device according to claim 31, comprising an enciphermentprocessing unit for executing mutual authentication with said accessrequesting device; wherein said access privilege determinationprocessing unit has a configuration for, under the condition that mutualauthentication has been established, executing signature verification ofthe group attribute certificate presented from said access requestingdevice, and screening regarding whether or not the device belongs to anaccess-permitted group.
 35. A communication processing device accordingto claim 31, further comprising an attribute certificate generating unitfor generating a group attribute certificate which has, as storedinformation, group identification information corresponding to a groupwhich is a set of certain communication devices or certain users, andalso has affixed an electronic signature of an issuer.
 36. Acommunication processing device according to claim 31, wherein saidgroup attribute certificate is of a configuration storing linkinformation regarding a public key certificate corresponding to saidgroup attribute certificate; and wherein said access privilegedetermination processing unit is of a configuration wherein verificationof the public key certificate obtained by said link information is alsoexecuted at the time of performing verification of said group attributecertificate.
 37. An access privilege management method for executingaccess restrictions between communication devices having communicationfunctions, said method comprising: a step for an access requestingdevice to transmit to an access requested device, which is the object ofan access request, a group attribute certificate which has, as storedinformation, group identification information corresponding to a groupwhich is a set of certain communication devices or certain users, andalso has affixed an electronic signature of an issuer; a step for saidaccess requested device to receive the group attribute certificatepresented by said access requesting device; a screening step forexecuting verification, by means of signature verification, of the groupattribute certificate presented from said access requesting deviceregarding whether or not there has been tampering, and performingscreening regarding whether or not said access requesting device is adevice which belongs to an access-permitted group based on groupidentification information stored in said group attribute certificate;and a step for executing determination regarding whether or not accesscan be permitted, based on the screening results in said screening step.38. An access privilege management method according to claim 37, whereinsaid access requested device performs screening regarding whether or notsaid access requesting device is an end entity belonging to anaccess-permitted group, based on a group attribute certificate issued tothe end entity which is an access executing device at said accessrequesting device, and executing determination regarding whether or notaccess can be permitted, based on said screening.
 39. An accessprivilege management method according to claim 37, wherein said accessrequested device performs screening regarding whether or not said accessrequesting device is a device owned by a user belonging to anaccess-permitted group, based on a group attribute certificate issued toa user identification device which is an individual identificationdevice at said access requesting device, and executing determinationregarding whether or not access can be permitted, based on saidscreening.
 40. An access privilege management method according to claim37, further comprising a mutual authentication execution step betweensecurity chips with anti-tampering configurations of said accessrequesting device and said access requested device; wherein, under thecondition that mutual authentication has been established, said accessrequested device executes signature verification of the group attributecertificate presented from said access requesting device, and screeningregarding whether or not the device belongs to an access-permittedgroup.
 41. An access privilege management method according to claim 37,further comprising a step for said access requested device to receivefrom a device an issuing request for a group attribute certificatecertifying that the device is an access-permitted group member; and astep wherein, under the conditions that mutual authentication betweendevices has been established and that the group attribute certificateissue requesting device is following an issuance policy permitted bysaid access requested device, a group attribute certificate is issued toa device corresponding to a device or a user.
 42. An access privilegemanagement method according to claim 37, further comprising, as anexecution step at said access requested device in response to an issuingrequest from a device for a group attribute certificate certifying thatthe device is an access-permitted group member, a step for executingprocessing for issuing a group attribute certificate to a devicecorresponding to a device or a user, certifying that the device is anaccess-permitted group member, under the conditions that mutualauthentication between devices has been established and thatverification and screening is established for an already-issued groupattribute certificate already held by the group attribute certificateissue requesting device.
 43. An access privilege management methodaccording to claim 37, wherein said group attribute certificate is of aconfiguration storing link information regarding a public keycertificate corresponding to said group attribute certificate; andwherein said access requesting device is of a configuration whereinverification of the public key certificate obtained by said linkinformation is also executed at the time of performing verification ofsaid group attribute certificate.
 44. A communication managing methodfor a communication processing device for executing access restrictionprocessing, said method comprising: a reception step for receiving, froman access requesting device, a group attribute certificate which has, asstored information, group identification information corresponding to agroup which is a set of certain communication devices or certain users,and also has affixed an electronic signature of an issuer; and an accessprivilege determination processing step for executing verification, bymeans of signature verification, of the group attribute certificatereceived from said access requesting device regarding whether or notthere has been tampering, performing screening regarding whether or notsaid access requesting device is a device which belongs to anaccess-permitted group based on group identification information storedin said group attribute certificate; and an accesspermissible/impermissible determination step for executing determinationregarding whether or not access can be permitted, based on the accessprivilege determination processing results.
 45. A communication managingmethod according to claim 44, wherein said access privilegedetermination processing step includes a step performing screeningregarding whether or not said access requesting device is an end entitybelonging to an access-permitted group, based on a group attributecertificate issued to the end entity which is an access executing deviceat said access requesting device.
 46. A communication managing methodaccording to claim 44, wherein said access privilege determinationprocessing step includes a step for performing screening regardingwhether or not said access requesting device is a device owned by a userbelonging to an access-permitted group, based on a group attributecertificate issued to a user identification device which is anindividual identification device making up said access requestingdevice.
 47. A communication managing method according to claim 44,further comprising an authentication processing step for executingmutual authentication with said access requesting device; wherein, insaid access privilege determination processing step, signatureverification of the group attribute certificate presented from saidaccess requesting device, and screening regarding whether or not thedevice belongs to an access-permitted group, are executed, under thecondition that mutual authentication has been established.
 48. Acommunication managing method according to claim 44, wherein said groupattribute certificate is of a configuration storing link informationregarding a public key certificate corresponding to said group attributecertificate; and wherein, in said access privilege determinationprocessing step, verification of the public key certificate obtained bysaid link information is also executed at the time of performingverification of said group attribute certificate.
 49. A computer programfor effecting execution of a communication managing method for acommunication processing device for executing access restrictionprocessing, said program comprising: a reception step for receiving,from an access requesting device, a group attribute certificate whichhas, as stored information, group identification informationcorresponding to a group which is a set of certain communication devicesor certain users, and also has affixed an electronic signature of anissuer; and an access privilege determination processing step forexecuting verification, by means of signature verification, of the groupattribute certificate received from said access requesting deviceregarding whether or not there has been tampering, performing screeningregarding whether or not said access requesting device is a device whichbelongs to an access-permitted group based on group identificationinformation stored in said group attribute certificate; and an accesspermissible/impermissible determination step for executing determinationregarding whether or not access can be permitted, based on the accessprivilege determination processing results.
 50. A data processing systemfor executing data processing accompanied by data communicationprocessing, between a plurality of devices capable of mutualcommunication, wherein, of said plurality of devices, a data processingrequesting device, which requests data processing to the other devicewith which communication is being made, holds a group attributecertificate which has, as stored information, group identificationinformation corresponding to a group which is a set of certain devicesor certain users, and also has affixed an electronic signature of anissuer, and transmits said group attribute certificate to a dataprocessing requested device at the time of data processing requestingprocessing; and wherein said data processing requested device executesverification processing of the received group attribute certificate,determines whether or not said data processing requesting device hasdata processing requesting privileges based on said verification, andexecutes data processing based on determination of privileges.
 51. Adata processing system according to claim 50, wherein the groupattribute certificate stored in said data processing requesting devicehas as the issuer thereof the data processing requested device, and hasaffixed the electronic signature of the data processing requesteddevice; and wherein said data processing requested device is of aconfiguration for executing electronic signature verification processingapplying a public key of itself, as verification processing of thereceived group attribute certificate.
 52. A data processing systemaccording to claim 50, wherein all of said mutually communicableplurality of devices are devices which mutually request data processingof the other device with which communication is being made, with each ofthe devices having a configuration storing the group attributecertificate issued by the communication party device and transmittingthe group attribute certificate stored in itself at the time of dataprocessing requesting of the other device with which communication isbeing made, and under the condition of verification being established atthe receiving device, processing corresponding to the data processingrequest is mutually executed.
 53. A data processing system according toclaim 50, wherein all of said mutually communicable plurality of deviceshave security chips with anti-tampering configurations, with mutualauthentication being executed between the mutual security chips at thetime of data processing requesting of the other device with whichcommunication is being made, and wherein, under the condition thatmutual authentication has been established, said transmission of groupattribute certificates between the devices, and verification of thetransmitted group attribute certificates, is executed.
 54. A dataprocessing system according to claim 50, wherein the group attributecertificate stored in the data processing requesting device has as theissuer thereof the data processing requested device; and wherein issuingprocessing is performed under the condition that mutual authenticationhas been established between the data processing requesting device andthe data processing requested device.
 55. A data processing systemaccording to claim 50, wherein, of said mutually communicable pluralityof devices, at least one or more devices comprise, as a deviceconfiguration, an end entity for executing communication processing withother device and data processing, and a user identification devicehaving individual identification functions capable of exchanging datawith said end entity; and wherein, in the event that said groupattribute certificate is issued to members making up a certain usergroup, issuing processing is carried out under the condition that mutualauthentication is established between said user identification deviceand a group attribute certificate issuing processing executing device.56. A data processing system according to claim 50, wherein, of saidmutually communicable plurality of devices, one is a maintenanceexecuting device for executing maintenance processing for devices; andwherein the other devices are service receiving device which receive themaintenance service from said maintenance executing device; and whereinsaid service receiving device stores a service attribute certificatewhich is a group attribute certificate issued by said maintenanceexecuting device; and wherein said maintenance executing device stores acontrol attribute certificate which is a group attribute certificateissued by said service receiving device; and wherein said serviceattribute certificate is applied for verification at said maintenanceexecuting device that said service receiving device belongs to a groupof devices or users having maintenance service receiving privileges; andwherein said control attribute certificate is applied for verificationat said service receiving device that said maintenance executing devicebelongs to a group of devices or users having maintenance serviceexecuting privileges.
 57. A data processing system according to claim56, wherein a maintenance program executed at said service receivingdevice is transmitted to or stored in said service receiving device asan enciphered maintenance program; and wherein said service receivingdevice is of a configuration for deciphering said enciphered maintenanceprogram within a security chip having an anti-tampering configuration,and then executing on said service receiving device.
 58. A dataprocessing system according to claim 56, wherein maintenance processingexecuted at said service receiving device is executed based on commandstransmitted from said maintenance executing device to said servicereceiving device; and wherein said service receiving device transmits aresponse to said maintenance executing device for the execution resultsof said commands, and said maintenance executing device executestransmission of new commands to said service receiving device based onthe transmitted response.
 59. A data processing device for executingdata processing based on data processing requests from a data processingrequesting device, said data processing device comprising: a datareception unit for receiving from said data processing requesting devicea group attribute certificate which has, as stored information, groupidentification information corresponding to a group which is a set ofcertain devices or certain users and also has affixed an electronicsignature of an issuer; a privilege determining processing unit forexecuting verification processing of the received group attributecertificate, and determining whether or not said data processingrequesting device has data processing requesting privileges based onsaid verification; and a data processing unit for executing dataprocessing based on determination of privileges.
 60. A data processingdevice according to claim 59, wherein said privilege determiningprocessing unit is of a configuration for executing electronic signatureverification processing applying a public key of itself, as verificationprocessing of the received group attribute certificate.
 61. A dataprocessing device according to claim 59, wherein said data processingdevice has a security chip with an anti-tampering configuration andcomprising an enciphering processing unit; and wherein said encipheringprocessing unit has a configuration wherein mutual authentication isexecuted with the data processing requesting device in response to adata processing request from the data processing requesting device; andwherein said privilege determining processing unit is of a configurationfor executing verification of the group attribute certificate, under thecondition that mutual authentication has been established.
 62. A dataprocessing device according to claim 59, wherein said data processingdevice is of a configuration comprising an attribute certificategenerating processing unit having functions for generating a groupattribute certificate which has, as stored information, groupidentification information corresponding to a group which is a set ofcertain devices or certain users, and also has affixed an electronicsignature.
 63. A data processing method for executing data processingaccompanied by data communication processing, between a plurality ofdevices capable of mutual communication, wherein, of said plurality ofdevices, a data processing requesting device, which requests dataprocessing to the other device with which communication is being made,executes a step for transmitting, to the other device with whichcommunication is being made at the time of data processing requestingprocessing, a group attribute certificate which has, as storedinformation, group identification information corresponding to a groupwhich is a set of certain devices or certain users, and also has affixedan electronic signature of an issuer; and wherein said data processingrequested device executes: a verification processing step for thereceived group attribute certificate; a step for determining whether ornot said data processing requesting device has data processingrequesting privileges based on said verification; and a step forexecuting data processing based on determination of privileges.
 64. Adata processing method according to claim 63, wherein the groupattribute certificate stored in said data processing requesting devicehas as the issuer thereof the data processing requested device, and hasaffixed the electronic signature of the data processing requesteddevice; and wherein, in said verification processing step at said dataprocessing requested device, electronic signature verificationprocessing applying a public key of itself is executed, as verificationprocessing of the received group attribute certificate.
 65. A dataprocessing method according to claim 63, wherein all of said mutuallycommunicable plurality of devices are devices which mutually requestdata processing of the other device with which communication is beingmade, with each of the devices having a configuration storing the groupattribute certificate issued by the communication party device andtransmitting the group attribute certificate stored in itself at thetime of data processing requesting of the other device with whichcommunication is being made, and under the condition of verificationbeing established at the receiving device, processing corresponding tothe data processing request is mutually executed.
 66. A data processingmethod according to claim 63, wherein all of said mutually communicableplurality of devices have security chips with anti-tamperingconfigurations, with mutual authentication being executed between themutual security chips at the time of data processing requesting of theother device with which communication is being made, and wherein, underthe condition that mutual authentication has been established, saidtransmission of group attribute certificates between the devices, andverification of the transmitted group attribute certificates, isexecuted.
 67. A data processing method according to claim 63, furthercomprising an issuing processing step for the group attributecertificate stored in the data processing requesting device; saidissuing processing step being executed under the condition that mutualauthentication has been established between the data processingrequesting device and the data processing requested device.
 68. A dataprocessing method according to claim 63, further comprising an issuingprocessing step for the group attribute certificate stored in the dataprocessing requesting device; wherein, in the event that said groupattribute certificate is issued to members making up a certain usergroup, said issuing processing step is executed under the condition thatmutual authentication is established with a user identification devicehaving individual identification functions making of the data processingrequesting device.
 69. A data processing method according to claim 63,wherein, of said mutually communicable plurality of devices, one is amaintenance executing device for executing maintenance processing fordevices, and wherein the other devices are service receiving devicewhich receive the maintenance service from said maintenance executingdevice, said method comprising: a step for said service receiving deviceto transmit to said maintenance executing device a service attributecertificate which is a group attribute certificate issued by saidmaintenance executing device; a service attribute certificateverification step for said maintenance executing device to executeverification of the received service attribute certificate; a step forsaid maintenance executing device to transmit to said service receivingdevice a control attribute certificate which is a group attributecertificate issued by said service receiving device; a control attributecertificate verification step for said service receiving device toexecute verification of said control attribute certificate; and amaintenance processing step for executing maintenance processing underthe condition that both verification of said service attributecertificate verification and said control attribute certificateverification have been established.
 70. A data processing methodaccording to claim 69, wherein a maintenance program executed at saidservice receiving device is transmitted to or stored in said servicereceiving device as an enciphered maintenance program; and wherein saidservice receiving device is of a configuration for deciphering saidenciphered maintenance program within a security chip having ananti-tampering configuration, and then executing on said servicereceiving device.
 71. A data processing method according to claim 69,wherein maintenance processing executed at said service receiving deviceis executed based on commands transmitted from said maintenanceexecuting device to said service receiving device; and wherein saidservice receiving device transmits a response to said maintenanceexecuting device for the execution results of said commands, and saidmaintenance executing device executes transmission of new commands tosaid service receiving device based on the transmitted response.
 72. Adata processing method for executing data processing based on dataprocessing requests from a data processing requesting device, saidmethod comprising: a data reception step for receiving from said dataprocessing requesting device a group attribute certificate which has, asstored information, group identification information corresponding to agroup which is a set of certain devices or certain users and also hasaffixed an electronic signature of an issuer; a privilege determiningprocessing step for executing verification processing of the receivedgroup attribute certificate, and determining whether or not said dataprocessing requesting device has data processing requesting privilegesbased on said verification; and a data processing step for executingdata processing based on determination of privileges.
 73. A dataprocessing method according to claim 72, wherein said privilegedetermining processing step includes a step for executing electronicsignature verification processing applying a public key of itself, asverification processing of the received group attribute certificate. 74.A data processing method according to claim 72, further comprising astep for executing mutual authentication with the data processingrequesting device in response to a data processing request from the dataprocessing requesting device; and wherein said privilege determiningprocessing step executes verification of the group attributecertificate, under the condition that mutual authentication has beenestablished.
 75. A computer program for effecting execution of dataprocessing based on data processing requests from a data processingrequesting device, said program comprising: a data reception step forreceiving from said data processing requesting device a group attributecertificate which has, as stored information, group identificationinformation corresponding to a group which is a set of certain devicesor certain users and also has affixed an electronic signature of anissuer; a privilege determining processing step for executingverification processing of the received group attribute certificate, anddetermining whether or not said data processing requesting device hasdata processing requesting privileges based on said verification; and adata processing step for executing data processing based ondetermination of privileges.